Tuesday, March 24, 2015< ^ >
Room Configuration
Room Occupants

[13:54:55] david.sinicrope joins the room
[14:15:48] <david.sinicrope> Andy opened the meeting at 9am and went through the Chair's slides.
No slides for RFC4447bis.  Will be presented slideless.
The Chairs requested that draft authors look at the charter and milestones and ensure they are accurate and realistic for the update prior to the next IETF.
Congratulations to Himanshu for the IPLS RFC after 11 years.
draft-ietf-pwe3-iccp-stp-03 is in IESG review. Being reviewed for English language.
See slides for WG drafts in or completed WG Last Call.
vccv-for-gal - went to IESG review
Andy reminded the working group that any work on Yang models in the Routing Area should be coordinated through the Routing Area Yang Coordinators.   See the Routing Area Yang Coordinator's Wiki.  
Dave commented that in addition to tracking Yang drafts, there is also an area of the wiki to announce intent to create a yang model and solicit in put and contributors from the community.
The Chairs encouraged everyone to take a look at the wiki and make good use of it.
[14:16:08] <david.sinicrope> Luca presenting 4447bis without slides.
[14:21:41] <david.sinicrope> Slideless presentation
Luca presented RFC 4447bis.  
Luca took all erratas over last 15 years and included in document.
It's stuff that has been around for a while and wanted to get it in the document and get a last look at it.
References were left as is, NOT updated to references that came out after the document.
The order of FEC 129 TLVs.
One implementation that sends in order in the picture and another that sends in random order. The doc doesn't say they need to be in any order.
No need to say you can send in any order, because implied.
The "fixed" and "next release" errata were all considered in the update.
Did all the "held for next revision".
Did you go through all the updated bys on RFC 4447?  No not yet.  We can do a reference.  Not keen to put in the text because text will change too much.
[14:24:01] <david.sinicrope> Document is well established and ready for proposed STD.  The documents are not at the same status.  
But we need to go through all the updated by, because this line will not be in the new RFC and the assumption is that the new document will include all of these RFCs.
Stewart and Luca will look at the updates offline and figure out how to proceed.
The path forward must address updates, but not cause document to linger.
[14:26:40] <david.sinicrope> Eric Gray: Regarding the order of TLVs.  Even if it doesn't say there is order and this implies it can go in any order, but if it is shown in a particular order then the implication is that it should be in that order.
Luca: The figure has an order, (it must), but it is clear the order is not dictated.  We could add clarifying text.
Eric: this would be helpful.  The implication is that if the TLVs MAY appear in any order, the receiver MUST accept in any order.
[14:33:20] <david.sinicrope> Himont going through slides on MAC Withdraw
[14:33:33] <david.sinicrope> himanshu not Himont
[14:38:55] <david.sinicrope> Sharam: eVPN also has MAC withdraw?
Himanshu: no this is for static based on LDP within an inband OAM channel
Sharam: how does the PE2 know there is a failure on the other link
Himanshu: there is the status signaling, but PE2 doesn't need to know. PE2 just forwards it.
[14:45:28] <david.sinicrope> Sharam: should call something other than OAM.
HImanshu: PW Status is also called OAM
Andy: if there is strong objection there should be comment on the list.
Himanshu: many idea here is don't keep sending traffic to the old one.  Take the old one down and let it broadcast and relearn
Andy: Chairs agree this is ready for WG Last Call
[14:45:43] <david.sinicrope> Seamless-BFD for VCCV - Stewart BRYANT for Carlos PIGNATARO
[14:50:30] <david.sinicrope> The tools page doesn’t have the slides yet.  Use to get the meeting slides
[14:55:57] <david.sinicrope> Stewart presented for Carlos
Need to discuss the capabilities - need to discuss the order of preference.  The question from the authors, can they be independent, no order of preference.  There is concern there, need to ensure two systems have expected behavior.
Greg Mirsky: compare SBFD to ICMP and LSP Ping.  More like ICMP Ping than LSP Ping.
Stewart: Two PW PEs need common agreement to run 1. just BFD, 2. BFD and SBFD or 3. just SBFD
Andy: personal druthers that we as a WG choose a default. No opinion as to which, but would like to see a default so if folks naively bring up systems it will just work
Stewart: I agree
Greg: In the case of ACH encap, there is no IP address to return to. How will a reflector know where to return to.  There is no state.
Stewart: there is PW state so you always know who your peer is. If you get something of the SBFD type, you take action and send it on the reverse PW (PW is always Bi Dir)  Not sure what happens when you have a p2mp PW. no return channel there. Need to figure that one out.
Andy: probably an IP return channel, but not sure, e.g., case of MPLS-TP
[14:58:07] <david.sinicrope> Stewart: please put comments on the list and we can discuss. The authors will ask for WG adoption
Robin: earlier said will not case LDP based l2vpn why not.
Stewart: They are not considered for this revision, but will most likely be addressed in future revisions.  Need to pick a default for negotiation.
[15:01:21] <david.sinicrope> Sharam: clarification - this runs over L2TP control or data, this runs over data right?
Stewart: signaling runs over control plane, and there is a bit in L2TP header saying this is OAM
Yuanlong: is this purpose to replace BFD?
Stewart: no, BFD exists anyway and don't see deprecating. This is to enhance BFD when you want to introduce scaling that can't be achieved with BFD.
Yanlong: This could also be used for MPLS PW, now have two options.  which should we use?
Stewart: depends on what you want to achieve.  The draft should discuss applicability of the options. (in particular when you want to run both)
[15:01:39] <david.sinicrope> Next up: - Yang Model for L2VPN - Zhenbin LI
[15:15:30] <david.sinicrope> Zhenbin (Robin) presented the slides
There will be a work plan created after the architecture design.
They will update the Yang Coordination Wiki as they progress the work.
The wiki can be found
Nick: should produce Yang models for RFCs we write
Greg: no problem having containers for implementation details
Andy: History - back in 90s... FR and ATM MIBs.  In each MIB there was a vendor neutral cross connect table.
[15:33:04] david.sinicrope leaves the room
[15:40:05] david.sinicrope joins the room
[15:41:07] david.sinicrope leaves the room
[16:18:04] david.sinicrope joins the room
[16:40:05] david.sinicrope leaves the room
[16:46:34] david.sinicrope joins the room
[17:47:35] david.sinicrope leaves the room
[18:10:20] david.sinicrope joins the room
[18:12:12] david.sinicrope leaves the room
[18:13:19] david.sinicrope joins the room
[18:15:07] david.sinicrope leaves the room
[18:20:37] david.sinicrope joins the room
[18:35:25] david.sinicrope leaves the room
[19:52:05] david.sinicrope joins the room
[19:53:07] david.sinicrope leaves the room
[20:16:09] Andy Malis joins the room
[20:16:31] Andy Malis leaves the room
[22:39:17] david.sinicrope joins the room
[23:56:10] david.sinicrope leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!