Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-ipfix-mpls-sr-label-type

[[e-mail]]

Hi Joe and Tianran,

Thanks a lot for the feedback and suggestions. This is much appreciated.

As you pointed out, I received a few feedbacks from LSR, MPLS, SPRING and OPSAWG. Especially thanks to

Sergey Fomin
Loa Andersson
Sabrina Tanamal
Erik Auerswald
Hannes Gredler
Paolo Lucente
Gyan Mishra
Ketan Talaulikar
Jeff Tantsura
Qin Wu
Tianran Zhou

I addressed the following points in the latest update:


  *   Support for BGP Prefix-SID in IE46
  *   Seamless MPLS SR as another use case description
  *   Which IE dimensions bring what kind of insights in describe label protocol migration scenarios. Both real life scenarios at Swisscom as network operator we are currently experiencing.
  *   Some typos fixed
  *   Removed "Segment Routing Segment Identifier Type" section

The diff can be seen here: https://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-tgraf-ipfix-mpls-sr-label-type-04.txt&url2=https://tools.ietf.org/id/draft-tgraf-ipfix-mpls-sr-label-type-05.txt<https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-tgraf-ipfix-mpls-sr-label-type-04.txt&url2=https://tools.ietf.org/id/draft-tgraf-ipfix-mpls-sr-label-type-05.txt>

Thanks to valuable vendor feedback from Sergey, Ketan and Jeff, I understood that the implementation of additional Segment Routing SID dimensions in IPFIX could be challenging since they are not currently present in the MPLS dataplane. There are other alternatives to retrieve Segment Routing SID dimensions for IE70, mplsTopLabelStackSection, such as draft-ietf-spring-sr-yang (https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-yang-22#section-8.3).

From Loa and Sabrina I understood that the current references in IE46 registry
https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mpls-label-type

            -------------------------------------------------------------------------------------------
            | Value| Description                                                          | Reference |
            |-----------------------------------------------------------------------------|-----------|
            | 0    | Unknown: The MPLS label type is not known.                           |  RFC3954  |
            |-----------------------------------------------------------------------------|-----------|
            | 1    | TE-MIDPT: Any TE tunnel mid-point or tail label                      |  RFC5102  |
            |-----------------------------------------------------------------------------|-----------|
            | 2    | Pseudowire: Any PWE3 or Cisco AToM based label                       |  RFC5102  |
            |-----------------------------------------------------------------------------|-----------|
            | 3    | VPN: Any label associated with VPN                                   |  RFC5102  |
            |-----------------------------------------------------------------------------|-----------|
            | 4    | BGP: Any label associated with BGP or BGP routing                    |  RFC5102  |
            |-----------------------------------------------------------------------------|-----------|
            | 5    | LDP: Any label associated with dynamically assigned labels using LDP |  RFC5102  |
            -------------------------------------------------------------------------------------------

should be listed under "Requester" and NOT under "Reference". "Reference" should be pointing to the document where the code point is described.

I requested another review of draft-tgraf-ipfix-mpls-sr-label-type-05 at the IPFIX doctor and requested to update IE46 registry to reflect Sabrina's feedback.

            -------------------------------------------------------------------------------------------------------
            | Value| Description                                                          | Reference | Requester |
            |-----------------------------------------------------------------------------|-----------|------------
            | 0    | Unknown: The MPLS label type is not known.                           |           |  RFC3954  |
            |-----------------------------------------------------------------------------|-----------|-----------|
            | 1    | TE-MIDPT: Any TE tunnel mid-point or tail label                      |  RFC4736  |  RFC5102  |
            |-----------------------------------------------------------------------------|-----------|-----------|
            | 2    | Pseudowire: Any PWE3 or Cisco AToM based label                       |  RFC3985  |  RFC5102  |
            |-----------------------------------------------------------------------------|-----------|-----------|
            | 3    | VPN: Any label associated with VPN                                   |  RFC4364  |  RFC5102  |
            |-----------------------------------------------------------------------------|-----------|-----------|
            | 4    | BGP: Any label associated with BGP or BGP routing                    |  RFC8277  |  RFC5102  |
            |-----------------------------------------------------------------------------|-----------|-----------|
            | 5    | LDP: Any label associated with dynamically assigned labels using LDP |  RFC5036  |  RFC5102  |
            -------------------------------------------------------------------------------------------------------


Once I received feedback from the IPFIX doctor, I will get in touch with LSR, MPLS, SPRING and OPSAWG again to receive some more feedback before I will come back to OPSAWG again. I hope that matches with your thoughts.

Best wishes
Thomas

From: OPSAWG <[e-mail]> On Behalf Of Joe Clarke (jclarke)
Sent: Thursday, September 3, 2020 5:03 PM
To: Joe Clarke (jclarke) <jclarke=[e-mail]>
Cc: opsawg <[e-mail]>
Subject: Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-ipfix-mpls-sr-label-type

Sorry for being late to close this out.

While there was a few support emails from opsawg, they were overshadowed by some technical concerns from the LSR WG (who arguably would be vested in the implementation of draft).  The chairs don’t feel that there is enough support to adopt this work in its current form in opsawg.

Our suggestion is to continue to work with the LSR, SPRING, and MPLS WGs to refine the approach to address the concerns that have been raised as well as include use case examples in the document to provide guidance on implementation and consumption.

Finally, there may need to be some cross-WG collab and support to progress this work in opsawg.  Hearing from those in the above-mentioned WGs would be helpful to know that they can help review the work when it is ready for adoption.

Thanks.

Joe and Tianran


On Aug 13, 2020, at 08:41, Joe Clarke (jclarke) <jclarke=[e-mail]<mailto:jclarke=[e-mail]>> wrote:

Hello, WG members.  During the IETF 108 virtual meeting, we had Thomas present this work.  It has been reviewed by SPRING as well as on this list.  The SPRING consensus was the work is better suited for opsawg.  The adoption hum during the IETF 108 virtual meeting was “Piano” which was middle of the road (though given the hum rules that is somewhat inconclusive).

Regardless, the chairs want to hear from the list.  This document aims to modernize the IPFIX MPLS label type for segment routing in order to provide more visibility for the MPLS-SR data plane.  Does opsawg want to adopt this work?

This starts a two-week call for adoption.  It will be concluded on August 27, 2020.

Joe
_______________________________________________
OPSAWG mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/opsawg