Hello Robert, Please see feedback inline [JL] Any other comments from folks in the alias?
From: [email protected] [mailto:[email protected]] On Behalf Of Robert Raszuk Sent: Tuesday, December 09, 2014 12:09 PM To: Jose Liste (jliste) Cc: [email protected] 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 [cid:[email protected]] Thx, r. On Tue, Dec 9, 2014 at 11:55 AM, Jose Liste (jliste) <[email protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]> 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 protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/bess
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
