Subject: Re: [Pals] draft-ietf-pals-ethernet-cw and enhanced heuristics

From: James Bensley <[email-masked]>
Date: Thu, 9 Nov 2017 10:42:49 +0000

On 25 October 2017 at 19:08, Stewart Bryant <[email-masked]> wrote:
> RFC6790 ought to be another way to address the problem, but as we noted a
> while ago in the SFL work it stops short of mandating DPI type LB.
>
> I think I therefore agree that we out to just use 6391, after all with that
> negotiated by both ends it would be rather silly to then do the DPI.
>
> Not sure if I will get the text done by Monday, but this thread should give
> everyone a heads-up, I will put it on the slides for discussion and if I
> don't get the draft out I will put it in some other accessible place.
>
> - Stewart

Hi guys,

Sorry I'm late with this response.

I think that saying FAT pseudowires or entropy labels SHOULD be used
when support is a suitable way forward I believe however, is it worth
putting something in the draft about enabling the PWMCW with
sequencing? Many devices support pseudowires that don’t support
FAT/ELI, is there benefit in adding to the draft, words to the effect
of:

“when FAT/ELI isn’t support, PWMCW SHOULD be used with sequencing,
even though it is known that the CW doesn’t fully resolve the issue of
packet reordering (such as with a XEROX MAC address), for that FAT/ELI
is required, but it does greatly reduce the likelihood and when
reordering does occur, it provides a mechanism to at least detect it”
?

I think it is a big problem that the packet reordering is not easily
detectable/diagnosable when using just a CW without sequencing.

Also on a side note, someone has probably pointed these out already
but just in case there are a few typos in the draft;

Draft:
Since that time the RAC has issued Ethernet MAC addresses start with
0x4 or 0x6

"....starting with..."

Draft:
used. This document updates RFC4448 [RFC4448] to state that where
both both the ingress PE and the egress PE support the Ethernet

"... both both..."

Draft:
as a data packet. This is described in detail section 7 of
[RFC6391], and section 6 of RFC6790.

"... detail in section 7..."

Draft:
Email: [email-masked]>

"...>"

Cheers,
James.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 9 Nov 2017 15:46:53 +0000

Hi James

Thank you for your comments.

I will look at the detailed editorial points in the next version.

However I don't know of any platforms that support CW S/N for Ethernet. 
In most forwarding architectures it is much easier to add FAT or ELI 
support than it is to add support for S/N. This is a discussion we are 
also having in DETNET.

Supporting FAT and ELI is a stateless operation that any forwarding 
architecture I can think of can support.

Supporting S/N is stateful. This is hard to so at speed, and may force 
the implementer to a specific forwarding architecture (egress packet 
filtering).

Given the above I am not in favour of including the text on CW S/N.

If members of the WG believe I am wrong in my assessment of the 
difficultly of implementing CW S/N or it turns out that it is 
implemented in a critical mass of platforms then I will change my 
position on this proposal.

Best regards

Stewart

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 9 Nov 2017 15:55:48 +0000

Stewart, 
I agree with your assessment of the difficultly of implementing CW S/N for Ethernet PWs.
And I am not aware of any implementation.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

-----Original Message-----
From: Pals [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Thursday, November 9, 2017 5:47 PM
To: James Bensley <[email-masked]>; [email-masked]; Andrew G. Malis <[email-masked]>; [email-masked]
Subject: Re: [Pals] draft-ietf-pals-ethernet-cw and enhanced heuristics

Hi James

However I don't know of any platforms that support CW S/N for Ethernet. 
In most forwarding architectures it is much easier to add FAT or ELI support than it is to add support for S/N. This is a discussion we are also having in DETNET.

Supporting FAT and ELI is a stateless operation that any forwarding architecture I can think of can support.

Supporting S/N is stateful. This is hard to so at speed, and may force the implementer to a specific forwarding architecture (egress packet filtering).

If members of the WG believe I am wrong in my assessment of the difficultly of implementing CW S/N or it turns out that it is implemented in a critical mass of platforms then I will change my position on this proposal.

Best regards

Stewart

On 09/11/2017 10:42, James Bensley wrote:
>> RFC6790 ought to be another way to address the problem, but as we 
>> noted a while ago in the SFL work it stops short of mandating DPI type LB.
>>
>> I think I therefore agree that we out to just use 6391, after all 
>> with that negotiated by both ends it would be rather silly to then do the DPI.
>>
>> Not sure if I will get the text done by Monday, but this thread 
>> should give everyone a heads-up, I will put it on the slides for 
>> discussion and if I don't get the draft out I will put it in some other accessible place.
>>
>> - Stewart
>
> Hi guys,
>
> used. This document updates RFC4448 [RFC4448] to state that where both 
> both the ingress PE and the egress PE support the Ethernet
>
> "... both both..."
>
> Draft:
> as a data packet. This is described in detail section 7 of [RFC6391], 
> and section 6 of RFC6790.
>

_______________________________________________
Pals mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pals

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 9 Nov 2017 16:04:11 +0000

Thanks.

I can explain why it is a hard problem if people need the background.

- Stewart

---

From: James Bensley <[email-masked]>
Date: Mon, 13 Nov 2017 20:03:10 +0000

Hi guys,

Thanks for your responses!

>> To: James Bensley <[email-masked]>;
>> [email-masked]; Andrew G. Malis <[email-masked]>;
>> [email-masked]
>> ... I don't know of any platforms that support CW S/N for Ethernet.
>> support than it is to add support for S/N. This is a discussion we are also
>> having in DETNET.

I’ve just jumped on to a couple of Cisco IOS boxes, they support it
(by which I mean the option is in the CLI, I didn’t test it). So if
something as wide spread as IOS supports sequencing I’d said it’s
fairly well supported (meaning deployed even if not used). Even so, I
am actually not disagreeing with you, I am in full agreement with you
that FAT or ELI should be used /when it can be/ however, my point here
is that no empirical data is being presented here about the support of
FAT, ELI and sequence number support from vendors, or the number of
operators that are using pseudowires are using any, a mixture, or none
of those techniques to avoid ECMP and what if any of the techniques
are available to those operators on their existing kit. So even though
I am in agreement with you, I don’t think sequence numbers can be
dismissed so easily (as my agreement is based upon my own cone of
vision which I know is very limited) for all the existing kit
operators have deployed that possibly supports sequencing.

>> Supporting S/N is stateful. This is hard to so at speed, and may force the
>> implementer to a specific forwarding architecture (egress packet filtering).
>>

I can't comment on how hard it is or isn't to implement sequence
numbers as I personally haven’t tried to code this. Although even
without trying I can understand that it adds in more state to the edge
devices, although debatably not alot more; RFC4385 provides an example
using two 16 bit counters and 2 booleans. I would expect any
reasonable pseudowire implementation to have 32 or 64 bit counters for
packets sent, received, bytes sent, received, drops on tx, rx, as well
as many others for uptime, last state change, etc etc... I don't think
it is wise to be flippant with device resources but in relative terms
I can’t see it being /that/ much state.

Also as I said in my first paragraph, if sequence numbers are support
in say Cisco IOS for example, the volume of existing devices that may
support PWMCW sequence numbers and not FAT and not ELI could be large,
so I would think it worth while to include sequence numbers as a last
resort recommendation to the operator.

Again, I am in full agreement with your recommendation for FAT or ELI
despite my lengthy email (sorry!) however, I would like to understand
clearly if/when/why sequence numbers shouldn’t be used.

Cheers,
James.

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Tue, 14 Nov 2017 01:45:51 +0000

Looks to me that we went from:

- people doing ECMP in a way that it was not intended for PW and getting into issues
to
- let’s try to solve the issues they run into with extra complexity, including discussions at the sessions or a below sequencing proposal 

I would rather go another way and clearly promote what can be done for ECMP  with the standard and by pointing that other “solutions” top attended to circumvent or “extend” technology are known to have run into issues of mis-ordering and thus operators should be careful enabling such “solutions” in a network.

Andrew

-----Original Message-----
From: Pals <[email-masked]> on behalf of James Bensley <[email-masked]>
Date: Tuesday, November 14, 2017 at 4:03 AM
To: Stewart Bryant <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Alexander Vainshtein <[email-masked]>, "Andrew G. Malis" <[email-masked]>
Subject: Re: [Pals] draft-ietf-pals-ethernet-cw and enhanced heuristics

    Hi guys,

    

    

    Cheers,
    James.