Subject: [mpls] Preliminary minutes from MPLS IETF92

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Wed, 15 Apr 2015 22:22:42 +0000

Hi all,

Below are the preliminary minutes taken during IETF92 MPLS sessions. Please let me know if you have comments or would like to update/change them.

MPLS Meeting notes for 24 and 27 March, IETF92
Materials are available at the following links:
Agenda
draft-fang-mpls-hsdn-for-hsdc
draft-ietf-mpls-spring-entropy-label
draft-kompella-mpls-rsvp-ecmp
draft-zheng-mpls-lsp-ping-yang-cfg-old
draft-chandra-mpls-enhanced-frr-bypass
draft-cheng-mpls-tp-shared-ring-protection
draft-dai-mpls-rsvp-te-mbb-label-reuse
draft-ietf-mpls-lsp-ping-relay-reply
draft-kompella-mpls-larp
draft-kompella-mpls-rmr
draft-mirsky-mpls-bfd-directed
draft-mirsky-mpls-residence-time
draft-openconfig-mpls-consolidated-model
draft-saad-teas-yang-te-rsvp
draft-tiruveedhula-mpls-mldp-mib
draft-mtaillon-rsvpte-summary-frr-00
IETF92_MPLS_WG_Status

Agenda:

Administrative (agenda bashing, WG status)
http://tools.ietf.org/html/draft-kini-mpls-spring-entropy-label
http://tools.ietf.org/html/draft-tiruveedhula-mpls-mldp-mib
http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-relay-reply
http://tools.ietf.org/html/draft-kompella-mpls-rsvp-ecmp
http://tools.ietf.org/html/draft-kompella-mpls-larp
http://tools.ietf.org/html/draft-kompella-mpls-rmr
http://tools.ietf.org/html/draft-cheng-mpls-tp-shared-ring-protection
http://tools.ietf.org/html/draft-mirsky-mpls-bfd-directed
http://tools.ietf.org/html/draft-mirsky-mpls-residence-time

Wednesday's minutes:
Sriganesh’s presentation on Spring Entropy Labels:
- No comments or questions.

Kishore’s presentation on P2MP and MP2MP LSP MIB:
- No comments or questions(?)

George Swallow’s presentation on LSP Ping relay reply:
- No comments or questions.

Kireeti’s presentation on Multi-path Label Switched Paths Signaled Using RSVP-TE:
- Kireeti asked for WG adoption and early IANA code point allocations.
- Himanshu Shah (Ciena) asked if you can do asymmetric bandwidth distribution.
- Kireeti said that you can do weighted distribution. There is neither an equal-cost nor an equal-distribution requirement.
- George had a rapid fire conversation with Kireeti that I did not capture any of.
- Eric Osborne asked a question (I didn’t get what the question was).
- Lou Berger asked for the format of the association object to be written down.
- Loa asked for improvements in the content of the IANA Considerations before making a request for early allocations.

Kireeti’s presentation on Labeled ARP:
- Kireeti asked for comments on the list, and adoption by the WG.
- Himanshu asked why this is required.
- Kireeti said that it is useful as a proxy ARP mechanism.

Kireeti’s presentation on resilient MPLS Rings:
- Greg Mirsky asked a question about timers – what would be the defaults and ranges?
- Greg was asked to wait until Kireeti had gotten further into his presentation.
- The question did not get answered, but – because of time constraints – needs to be taken to the list.
- George asked if you can break up the bundles talked about in the draft.
- Kireeti said that you can.
- Greg Mirsky asked questions on ring interconnectivity, which Kireeti answered.
- The answer was that nodes advertise ring ID on particular links so this is a link property.  This should be clarified in the next version.
- George asked a question about (?) that Kireeti said would be answered on the next slide.
- Greg asked a question about manual switch-over – is it in the draft?
- Kireeti said that specific support details (Lock/Unlock controls, etc.) are not in the current draft and will be in future work.
- Ross Callon asked for a clarification of the meaning of maximally connected rings.
- Stewart Bryant asked how you can distinguish clockwise and “anti-clockwise” directions on the ring.  Kireeti said that it is explained in the draft.
- Eric Osborne observed that there is some history of ring work in MPLS.
- (?) from Huawei asked a couple of questions.
- Kireeti answered one question by saying that irregular rings require the same sort of configuration information.
- Kireeti explained the motivation for using RSVP-TE.
- Kireeti punted on the MRT question, due to time limits.
- Li Weng (Comcast) asked how you would protect a ring under specific failure scenarios.
- This discussion would need to be continued on the list.
- Stewart asked how this proposal would work if one or more parts of a ring failed to come up.
- Further discussion will need to be taken to the list.

Liang Geng’s (China Mobile) presentation on MSRP:
- Weiqiang asked for feedback from the WG and to determine if the draft might be ready for adoption.
- Kireeti and George asked questions about where on a ring the decision is made for traffic exiting the ring.
- Shahram Davari answered.
- Eric Osborne said that this draft needs some discussion as to why the existing RFC(s) are inadequate.
- Loa asked if this observation applies to both this draft and Kireeti’s draft.
- Eric said that – in his opinion – Kireeti’s draft already provides enough info to distinguish its applicability.

Greg Mirsky’s presentation on Directed BFD Return Path status:
- No comments or questions.

Greg Mirsky’s presentation on Residence Time Measurement:
- Shahram Davari asked why the format in the draft was used.  It seems to be more than is needed.
- Greg said that we chose to use the same format as was used in IEEE 1588.
- Shahram asked if the draft allows for further extensions, giving an example.
- Greg said that additional sub-TLVs could be defined.

Friday's minutes:
Tarek's presentation on MPLS RSVP and TE related Yang actvites
- No comments or questions.

Kamran's presentation on MPLS LDP related YANG model
- No comments or questions.

Greg's presentatio on draft-zheng-mpls-lsp-ping-yang-cfg
- No comments or questions.

Ina's OC-MPLS YANG model draft-openconfig-mpls-consolidated-model

Luang's presentation on draft-fang-mpls-hsdn-for-hsdc
- TBD

Stewart's presentation on draft-bryant-mpls-flow-ident
- TBD

Stewart's presentation on idraft-bryant-mpls-sfl-control
- TBD

Ron's presentation on draft-bonica-mpls-self-ping
- TBD

Tarek's presetnation on draft-mtaillon-mpls-summary-frr-rsvpte
- Lou aksed why not use RSVP message bundles
- Tarek answered, still with message bundles, for 10000's of states, likely you'll need to send 1000's of messages and the receiver will have to parse and process all messages

Chandra's presentation on draft-chandra-mpls-enhanced-frr-bypass
- No comments or questions.

Minjie's presentaiton on draft-dai-mpls-rsvp-te-mbb-label-reuse-00
- No comments or questions.

Regards,
Tarek

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 20 Apr 2015 22:19:29 +0200

All,

In:

> Below are the *_preliminary_* minutes taken during IETF92 MPLS sessions.

> - Eric said that – in his opinion – Kireeti’s draft already provides
> enough info to distinguish its applicability.

Section 2.3 of draft-cheng-mpls-tp-shared-ring-protection
describes the Configuration Complexity.

I will try to provide some more details:

Suppose a ring with N nodes.
---------------------------
Applying RFC6974 means that from every ring-node a linear
protection configuration has to be provisioned with every other
node in the ring, i.e. with (N-1) other nodes.
This means that in every node there will be (N-1) instances of
the PSC protocol.
In order to detect faults and to transport the PSC OAM each
instance shall have a MEP on the working path and a MEP on the
protection path. (A MEP == co-located so_MEP and sk_MEP).
This means that every ring-node should have the capability to
support (N-1) * 2 MEPs.

Applying draft-cheng-mpls-tp-shared-ring-protection means that
in every ring-node there will be a single instance of the MSRP
protocol.
In order to detect faults and to transport the MSRP OAM each
instance (e.g. in node N) shall have a MEP on the working path
and a MEP on the protection path to node (N-1) and also to
node (N+1).
This means that every ring-node should have the capability to
support 2 * 2 MEPs.

Suppose a ring with N nodes, and one node has to be added:
---------------------------------------------------------
Applying RFC6974 means that every existing ring-node has to
be updated: a new PSC protocol instance created, and 2 MEPs
instantiated.
In the new node N PSC instances have to be created and
N * 2 MEPs instanciated.

Applying draft-cheng-mpls-tp-shared-ring-protection means that
in every existing ring-node the ring-map has to be extended.
In the new node a single MSRP instance has to be created and
4 MEPs instantiated.
Note that the 4 MEPs have to be instantiated anyway to be able
to monitor the links with the adjacent ring-nodes, so in fact
only the MSRP OAM has to be enabled.

Regards, Huub.

-- 
*****************************************************************
               请记住，你是独一无二的，就像其他每一个人一样