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 <opsawg-boun...@ietf.org> On Behalf Of Joe Clarke (jclarke)
Sent: Thursday, September 3, 2020 5:03 PM
To: Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org>
Cc: opsawg <opsawg@ietf.org>
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=40cisco....@dmarc.ietf.org<mailto:jclarke=40cisco....@dmarc.ietf.org>> 
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
OPSAWG@ietf.org<mailto:OPSAWG@ietf.org>
https://www.ietf.org/mailman/listinfo/opsawg

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to