Re: [manet] DLEP Credit Windowing

Hi Ashish,

Introducing a VLAN per neighbour is actually quite a big change from 
core DLEP.  Destinations (neighbours) in DLEP are distinguished by MACs 
that are MUST be addressable/reachable on the same (V)LAN segment as the 
DLEP peers.

What you are proposing with VLAN-per-destination looks a lot more like 
the draft extension I put forward for layer-3 DLEP 
(https://tools.ietf.org/html/draft-taylor-manet-l3-dlep-00) where I 
proposed the workaround of stating that the MAC address is no longer a 
MAC, just an identifying unique sequence of octets.

In your case the additional VLAN-Id data item paired with the MAC 
becomes the unique destination identifier.

Might I suggest that you actually have 2 extensions in this one draft: 
Per-VLAN destinations, and PFC based flow control?  Maybe splitting the 
document into two might be clearer for the readers?

Cheers,

Rick

On 04/03/16 12:26, Ashish Dalela (adalela) wrote:
> Hi Rick,
>
> Yes, one of the proposals is to use a VLAN per neighbor. The default VLAN 1 will be used for the control plane. That allows us to have 4K neighbors, each distinguished by a unique VLAN ID.
>
> Thanks
>
> Ashish
>
> -----Original Message-----
> From: Rick Taylor [mailto:rick@tropicalstormsoftware.com]
> Sent: Friday, March 04, 2016 5:17 PM
> To: Ashish Dalela (adalela) <adalela@cisco.com>; Stan Ratliff <ratliffstan@gmail.com>; Henning Rogge <hrogge@gmail.com>
> Cc: manet@ietf.org
> Subject: Re: [manet] DLEP Credit Windowing
>
> Hi Ashish,
>
> Thank you for this, it looks extremely interesting.
>
> Obviously I haven't had a chance to completely digest the draft, but one thing that leaps out to me is the use of VLAN tagging, specifically section 7.  Are you suggesting that the DLEP session runs over a VLAN trunk between router and modem (somehow) and the VLANs then fan out at the modem in some way?
>
> Given the 'transparent layer-2' requirement of DLEP, how do you see this working with your model of a VLAN per destination (for flow control), or have I misunderstood what you are proposing?
>
> Regards
>
> Rick
>
> On 04/03/16 10:43, Ashish Dalela (adalela) wrote:
>> Hello Stan,
>>
>> We have submitted a new draft today to describe the PFC flow control
>> mechanism. Sorry, this was long due on me; but better late than never!
>>
>> https://datatracker.ietf.org/doc/draft-dalela-dlep-flow-control/
>>
>> Here is the quick rationale underlying this draft. The current DLEP
>> credit window scheme requires credits exchanged over a TCP session.
>> This is harder to achieve in many scenarios because many data path
>> implementations are incapable of handling TCP windowing. So we are
>> suggesting an alternative approach that utilizes IEEE 802.1Qbb (a.k.a.
>> PFC).
>>
>> Request comments.
>>
>> Thanks
>>
>> -Ashish
>>
>> *From:*Stan Ratliff [mailto:ratliffstan@gmail.com]
>> *Sent:* Friday, October 16, 2015 2:34 AM
>> *To:* Ashish Dalela (adalela) <adalela@cisco.com>
>> *Cc:* Henning Rogge <hrogge@gmail.com>; manet@ietf.org
>> *Subject:* Re: [manet] DLEP Credit Windowing
>>
>> Ashish,
>>
>> If you'd like to write a proposed DLEP extension using PFC, I
>> encourage you to do so. As Henning mentioned, more than 1 flow control
>> mechanism is likely for DLEP.
>>
>> Stan
>>
>> On Thu, Oct 15, 2015 at 10:49 AM, Ashish Dalela (adalela)
>> <adalela@cisco.com <mailto:adalela@cisco.com>> wrote:
>>
>>      Yes it will and that's why I suggested the use of PFC. The control
>>      and data planes will have different priorities. The radio never
>>      pauses the control channel because it is never sent over the air. If
>>      desired,  the data packets themselves could be given different
>>      priorities allowing some flows to be selectively paused.
>>
>>      Sent from Samsung Mobile
>>
>>
>>
>>      -------- Original message --------
>>      From: Henning Rogge
>>      Date:15/10/2015 18:36 (GMT+05:30)
>>      To: "Ashish Dalela (adalela)"
>>      Cc: manet@ietf.org <mailto:manet@ietf.org>
>>      Subject: Re: [manet] DLEP Credit Windowing
>>
>>      On Thu, Oct 15, 2015 at 2:25 PM, Ashish Dalela (adalela)
>>      <adalela@cisco.com <mailto:adalela@cisco.com>> wrote:
>>      > The ideal mechanism for Ethernet flow control is the use of 802.3 PAUSE
>>      > frames, which has further been enhanced by the PFC (802.1Qbb) mechanism. In
>>      > essence, we don't send credits before packets are forwarded. Rather we pause
>>      > the traffic when the traffic cannot be forwarded and the buffers are full.
>>      > PFC is widely used in a number of Ethernet flow-control scenarios today.
>>
>>      Would a 802.3 PAUSE Frame not also block the DLEP control channel?
>>
>>      Henning Rogge
>>
>>
>>      _______________________________________________
>>      manet mailing list
>>      manet@ietf.org <mailto:manet@ietf.org>
>>      https://www.ietf.org/mailman/listinfo/manet
>>
>
>