Subject: Re: [bess] BESS - soliciting WG adoption - draft-keyupate-l2vpn-fat-pw-bgp

From: "Jose Liste (jliste)" <[email-masked]>
Date: Tue, 10 Feb 2015 19:43:57 +0000

Hello Robert,
Please see feedback inline [JL]

Any other comments from folks in the alias?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, December 09, 2014 12:09 PM
To: Jose Liste (jliste)
Cc: [email-masked]
Subject: Re: [bess] BESS - soliciting WG adoption - draft-keyupate-l2vpn-fat-pw-bgp

Hi Jose,

Great signature :)

One observations. The draft says:

"When the bit value is 1, the PE is requesting the ability

to send a Pseudowire packet that includes a flow label."

How can PE "request the ability" by setting a bit flag ?

[JL]During the PW signaling phase, the T/R bit flag values in the outgoing / incoming NLRIs will indeed allow a PE to determine whether it can use / expect flow labels on a given PW direction

I recommend if you want to keep it you replace the "requesting the ability" by "indicating the ability".

[JL] The T-bit indicates more than ability to transmit. It means desire to transmit (which of course requires it to be capable). For backwards compatibility, with T = 0, a non-capable (legacy) PE would transmit the same value as a capable one that does NOT wish to transmit FL

For consistency, please note that we are keeping the T/R bit definitions aligned with RFC6391

But is there any real use case for T flag at all ? What happens if node first advertised that it can not include flow label, but then sends packets to egress PEs with flow label ? Would you drop such packets?

[JL] Re-programming of data-plane after signaling and contradicting what was signaled should be treated as a defect in the PEs implementation. PWs must be re-signaled before making such change. Back to the hypothetical scenario, the egress PE is programmed NOT to expect flow labels. Any PW traffic arriving with “unexpected” FL will treat it (FL) as service delimiting (VC label). This will most likely translate to traffic being dropped (i.e. egress PE has no context for the label value) or in the worst case, could cause miss-merge

For completeness, see below a slide with the different states associated to T/R

Regards,

Jose

Thx,

r.

On Tue, Dec 9, 2014 at 11:55 AM, Jose Liste (jliste) <[email-masked]<mailto:[email-masked]>> wrote:
Hi BESS WG,

Draft “draft-keyupate-l2vpn-fat-pw-bgp” proposes protocol extensions required to synchronize flow label states among PEs when using the BGP-based signaling procedures defined in RFC4761 / RFC6624
https://tools.ietf.org/html/draft-keyupate-l2vpn-fat-pw-bgp-03

We have presented this draft a couple of times in the L2VPN WG.

We would now like to solicit comments from the BESS WG. We believe that the draft is ready for WG adoption.

We request chairs and WG to consider adopting the draft as a WG document.

Best Regards,

[http://www.cisco.com/web/europe/images/email/signature/horizontal01.jpg]

Jose Liste
ENGINEER.TECHNICAL MARKETING
Corporate Development
[email-masked]<mailto:[email-masked]>
Phone: +1 408 527 3369<tel:%2B1%20408%20527%203369>

Cisco.com<http://www.cisco.com>

[Think before you print.]Think before you print.
This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess