[j-nsp] Limit on interfaces in bundle

[Adam Vitkovsky]

Hi Jesper,

>

        Adam Vitkovsky
        IP Engineer

T:      0333 006 5936
E:      Adam.Vitkovsky at gamma.co.uk
W:      www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster at gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


-----Original Message-----
> From: juniper-nsp [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of
> Jesper Skriver
> Sent: Monday, November 02, 2015 1:31 PM
> To: Saku Ytti
> Cc: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] Limit on interfaces in bundle
>
> On Sun, Nov 01, 2015 at 05:06:22PM +0200, Saku Ytti wrote:
> > On 1 November 2015 at 12:08, Jesper Skriver <jesper at skriver.dk> wrote:
> >
> > > To do what you suggest, one either has to replicate the MPLS table,
> > > so that we can handle the same label values for each of the
> > > suggested MPLS-IPv4, MPLS-IPv6, MPLS-XX, MPLS-YY, with the only
> > > different being that they link to different L2 rewrite objects that
> > > set the appropriate ethertype. Or alternatively, one has to carry
> > > forward information about the ethertype of the received packet, and
> > > use it when sending the outgoing packet.
> > >
> > > Neither is practical.
> >
> > Like 8847, all these would go out with same ethertype it came in.
> > Lookup would be exactly the same as 8847, only behavioural difference
> > would be, what bits are used for balancing.
>
> Saku,
>
> The point is that the incoming ethertype is only used to determine how to
> interprete the header (IPv4, IPv6, MPLS etc) and to select what L3 table to
> lookup in. After that it is gone, and never used again.
>
> The L3 lookup result in a rewrite operation, which will impose a new L2 encap
> with associated ethertype on the packet. This ethertype is statically
> programmed into this rewrite object, and is completely independent of the
> ethertype of the received packet.
>
> So to do what you suggest, there are two options
>
> 1) Keep all the logic as today, but for different received
>    ethertypes point to different L3 tables, that result in
>    different rewrite objects that ensure the outgoing packets
>    have the different ethertypes requested.  This require that you
>    replicate the MPLS table for each of your ethertypes.
>
> 2) Change the logic such that the incoming ethertype is
>    remembered, and on egress do not use a static ethertype, but
>    instead do something like
>       if ( input ethertype is one of the MPLS ones &&
>            output ethertype is 'mpls' &&
>            no operation performed changed the nature of the payload ) {
>          output_ethertype = input_ethertype
>       }
>

I don't see any problem with adjusting rewrite objects dynamically based on the ingress properties (like during QOS).
It only depends on what is defined as rewrite object (I guess those are the bits(fields) that should be constant).
But I would argue that the only piece that will always be constant is the source MAC address.

adam