[mpls] Preliminary minutes: MPLS WG - Session 1 - Wed Nov 4th 9 am

["Tarek Saad (tsaad)" <[e-mail]>]

Hi all,

Minute taker: Kamran Raza (thanks Kamran).

Below are notes of MPLS WG - Session 1. Please review and feel free to suggest corrections.

  *   Chair: Loa + Andy Mallis (help)
  *   Chair update: Loa
     *   NOTE WLLL and update.
     *   Agenda Bashing + Blue sheets
     *   WG Status
     *   NOTE-WELL
     *   Daniel King: He gave a short update on his draft: ???
     *   Icmp-bie draftr: should we move it to BIER ?
     *   IPR’s in future polls: How to discuss IPR discussions on list ? IPR disclosure to IESG with simple state
  *   chandra: RSVP refresh-interval
     *   In MPLS RT review
  *   ryoo: MPLS TP … RFC 7271
     *   4-5 ppl read  the draft; Loa asked to ask/seek comment on mailing list.
  *   santosh: app-aware-tldp
     *   Loa: Make it active on alias
     *   Andy: Overlap with PALS – send an email to PALS WG , intro to the draft and seek comments.
     *    Several ppl have read the draft, and support WG LC.
     *   Loa: Too many authors on the 1st page … Max 6 ppl please.
  *   santosh: Node Prot for LDP LSPs
     *   Loa comments: Requirements are very generic. Will like to look and might ask for rewrite the req section of the doc.
     *   Jeff Tantsura: Ericsson: Like to see real reason for doing something else than LFA (proven). Possibly Some data on LFA SPF vs LDP.
        *   Present in rtgwg
     *   Autumn (??? L2VPN YANG llady) Ericsson: Why node protection with two protocols involved ? (IGP is always there)?
     *   Chris Bowers (JNPR): RSVP/TE Tunnel scalability when used e2e (100 of 100s of transit LSPs)… Using RSVP/TE *only* for protection is not an issue.
     *   Robin (Huawei):  LFA does not provide all the coverage
     *   Loa: slide mentioned: mLDP protection for free ? Does current draft has this info. Clarify in the document.
     *   Jeff: Read mLDP Node Protection. Also get feedback from SPs
     *   Good # of ppl read the draft; Lesser # of ppl for WG adoption.
  *   tarek: LSP instant install
     *   Shahram Davari: It is not a good idea. With number of hops increase, the stack depth increases and .
     *   Chandra (JNPR): Is the primary motive is due to scale of LSPs on transit LSRs ? Tarek: Not really. It is due to race b/w fwding programming and signaling upstream. Eliminating current “wait” time will eliminate this issue.  >>> Loa: Move this discussion on mailign list.
     *   Kireeti (JNPR): Overall idea is good but need to see how many distraction occur on traffic and how to deal with it?
     *   Chris Bowers (JNPR): It will be helpful to post the slides on the material section of the MPLS WG for overall discussion.
     *   Ina (GOOG): Couple of concerns with deployability of this solution (on ingress – num of labels) + how to account for LSP ? Tarek: Is it more ingress or transit side concern ? Loa: Take it to the mailing list.
  *   deborah: Loa: Requirements when we we update/change the status of an RFC ?
     *   RFC 6410: Proposed and Internet Standard levels
     *   What is an “IS” and How much can revise from the original RFC.
     *   RFC 5036 can be moved from PS to IS. PALS need it for RFC 4447.
     *   Carlos P. / Cisco: One goal is to cleanup the doc + other is to move it in standardization.
     *   Adrian: Why do we need to spend cycles on this ?
     *   Chris Bowers (JNPR): Selectively moving some items from PS to IS might confused ppl for the documents which remain as PS. Loa/Deborah: This is not WG choice but pushed by.
  *   carlos: rfc 4379bis
     *   carlos: Two Qs for WG/chairs: Is it useful work ? What needs to be brought in ?
     *   loa: in view of deborah’s preso on PS->IS, …
     *   Carlos: this is a WG RFC and we need to take it to WG ASAP. Loa: Will initiate.
  *   Kireeti: RMR
     *   Eric Gray (Ericsson): re: U-shaped rings: we need to know more about the use, cost etc – before we go and update the draft.
     *   Luyan: MS: It is a good concept. Need to look for beyond shortest path.
  *   Kireeti: LARP
     *   No slides
     *   Andy Mallis:  HUWEI: Q1: There must be some high use case for overloading ARP. Kireeti: ARP is not an ehternet protocol.. Can be used for other hardware/atm etc. There is H/W field that is going to be updated for LARP.  Q2: Security section is weak. Kireetai: ARP security is already low… there are security issues that we are inheriting…
  *   Luyan: forwarding-no-swap:
     *   Eric Gray : Ericsson: Not all the Q on the mailing list have been answered.
     *   Kireeti: It is not a matter of English but technical. Adding another operation is not a good idea. There are other things in the MPLS header besides label .. TTL etc… These bits need processing.
     *   Fabio Chiussi: Stabdard need to change to support most efficient impl (no-swap).
     *   Xia Chen : Huawei: It is important to clarify label operations in view of SR standardization.
     *   Robin Huawei: We propose domain wide labels;
     *   Shahram:  Broadcomm: Support this draft from chip implementation.
  *   Luyan: SDN
     *   Loa: Is it a good doc or interest for industry. Make it Informational ?  Should this be not an MPLS WG doc ?
     *   Robin : Huawei:
  *   Robin: Global label use case
     *   Loa: Out of time – take on the list.
     *

Regards,
Tarek