Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[Shraddha Hegde]

I am not aware of any undisclosed IPR.

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Christian Hopps  
Sent: Tuesday, August 18, 2020 5:00 AM
To: lsr@ietf.org
Cc: Christian Hopps ; lsr-...@ietf.org; Acee Lindem (acee) 
; draft-ietf-lsr-flex-algo@ietf.org
Subject: WG Last Call for draft-ietf-lsr-flex-algo

This begins a 2 week WG Last Call, ending after September 1st, 2020, for 
draft-ietf-lsr-flex-algo

  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

All authors, please indicate by sending an email to the list, whether you aware 
of any other IPR beyond what is already posted:

  [From 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-flex-algo]

  https://datatracker.ietf.org/ipr/3910/
  https://datatracker.ietf.org/ipr/3248/

Thanks,
Chris & Acee.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[Ketan Talaulikar (ketant)]

As a co-author, I am not aware of IPR beyond what has been already disclosed on 
this document.

Thanks,
Ketan

-Original Message-
From: Christian Hopps  
Sent: 18 August 2020 05:00
To: lsr@ietf.org
Cc: Christian Hopps ; lsr-...@ietf.org; Acee Lindem (acee) 
; draft-ietf-lsr-flex-algo@ietf.org
Subject: WG Last Call for draft-ietf-lsr-flex-algo

This begins a 2 week WG Last Call, ending after September 1st, 2020, for 
draft-ietf-lsr-flex-algo

  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

All authors, please indicate by sending an email to the list, whether you aware 
of any other IPR beyond what is already posted:

  [From 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-flex-algo]

  https://datatracker.ietf.org/ipr/3910/
  https://datatracker.ietf.org/ipr/3248/

Thanks,
Chris & Acee.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[tony . li]

> This begins a 2 week WG Last Call, ending after September 1st, 2020, for 
> draft-ietf-lsr-flex-algo
> 
>  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/



Hi,

I’d like to raise an objection.

Recently, I requested (and I thought that Peter agreed to) a clarification of 
the Min Unidirectional Link Delay.

As of version -08, the draft references RFC 7810 for the Metric-type in Section 
5.1.  

That RFC defines both a “Unidirectional Link Delay” (section 4.1) and “Min/Max 
Unidirectional Link Delay” (section 4.2).

I requested that the reference be extended to specify the section.

Instead, as of -09, the reference has been changed to refer to 
ietf-isis-te-app.  This is somewhat helpful becuase it makes it clear that this 
should be found
in the Application Specific Link Attributes Sub-TLV, but it still does not 
resolve the ambiguity of which sub-sub-TLV should be used.

I would again request that this be clarified.  Proposed text:

1: Min Unidirectional Link Delay as defined in [RFC 7810], section 4.2, 
encoded in the Application Specific Link Attributes Sub-TLV 
[I-D.ietf-isis-te-app].


Thank you.

Regards,
Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[Christian Hopps]

This begins a 2 week WG Last Call, ending after September 1st, 2020, for 
draft-ietf-lsr-flex-algo

  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

All authors, please indicate by sending an email to the list, whether you aware 
of any other IPR beyond what is already posted:

  [From 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-flex-algo]

  https://datatracker.ietf.org/ipr/3910/
  https://datatracker.ietf.org/ipr/3248/

Thanks,
Chris & Acee.



signature.asc
Description: Message signed with OpenPGP
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

[Ketan Talaulikar (ketant)]

Hi Thomas,

Please check inline below.

From: thomas.g...@swisscom.com 
Sent: 15 August 2020 11:31
To: Ketan Talaulikar (ketant) ; han...@gredler.at
Cc: lsr@ietf.org; spr...@ietf.org; ops...@ietf.org
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Ketan,


  *   This helps identification of specific SR-MPLS segment types as well as 
differentiating them from LDP, RSVP-TE, etc.

To be precise, the existing MPLS Label Type identifier differentiates from LDP, 
RSVP-TE. Not the new SrSidType IPFIX IE being proposed.
[KT] Why not extend the existing IPFIX MPLS Label Type (value 46) to add SR 
Prefix SID, SR Adjacency SID, SR Binding SID ... (basically the segment types 
from RFC8402)? It's a simpler change to an existing element/field that makes it 
easier for routers, collectors and analysers?


  *   What value is provided for IPFIX analysis if the SR Prefix SID was being 
signalled via OSPF or ISIS?

It is important to distinguish between intend and result.
[KT] By giving different types for OSPF and ISIS, is the intention to 
troubleshoot routing preference selection (done based on "admin distance" 
between protocol selection in RIB)?

If you migrate from one label distribution protocol to another, a network 
operator want's to understand if the data plane is still forwarding packets 
with the label distribution protocol which needs to be removed or not. IE46 
enables that by looking at the result of the forwarded traffic and not at the 
intend. RFC 8661 section 3, https://tools.ietf.org/html/rfc8661#section-3, 
describes the context.
[KT] Sure, so adding the SR Segments to IE46, one can check whether the traffic 
forwarding is happening using LDP or SR labels at any link in the network.



  *   What value is provided for IPFIX analysis if it was a Adjacency SID or a 
LAN Adjacency SID?

Quote from RFC8402. "Segment Routing (SR) leverages the source routing 
paradigm". Means that not the routing protocol does all the forwarding 
decisions, the node can change the forwarding by pushing additional labels.
[KT] From the document, I believe we are still talking only about the top of 
the stack label ...

With IPFIX SrSidType we are able to cover this dimension in IPFIX. Enabling to 
analyze the result of this decision. The example with " Adjacency SID or a LAN 
Adjacency SID" is not very useful because the difference of the two is the 
topology among the adjacency. If you compare " Adjacency SID with Prefix SID", 
that makes much more sense. Since it describes that a particular adjacency is 
chosen to forward the packet instead of a prefix. If IE 89, ForwardingStatus is 
drop, we understand that result of that decision lead to the drop and this 
enables to narrow down forwarding issues in segment routing networks more 
efficiently and quickly.
[KT] My point is why do we need to introduce another ElementID and why not use 
the existing Type 46 as suggested above?


  *   am asking for WG to weigh the implementation complexities

For the WG and me, I would be important if you can describe more detailed what 
you mean with implementation complexities. I would like to have a better 
understanding where your fear is coming from. I would appreciate if you could 
differentiate between MPLS Label Type identifier, IE46, from which label 
protocol the label was coming from and SrSidType which SID type was used..
[KT] To be clear, I am not talking from the POV of a specific implementation. 
Let me summarize my feedback and perspective:

  *   Carefully consider the addition of more control plane elements and 
nuances into IPFIX since they require all that additional context/information 
to be made available at the "layer" (or component) from where IPFIX picks this 
info (traditionally from the "FIB"). This added information should have a 
strong enough justification of benefit - e.g. How does difference between Adj 
SID and LAN Adj SID matter?  How relevant it is to determine if the SR 
signaling protocol is OSPF or ISIS?
  *   Try to add/extend existing elements/fields with just the right amount and 
sufficient information that is necessary for flow analysis. We need to note 
that there may be many more/other sources for "off-box enrichment" of flow 
information collected and perhaps not everything needs to be determined and 
reported by routers.

Thanks,
Ketan

Best wishes
Thomas

From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Saturday, August 15, 2020 7:09 AM
To: Graf Thomas, INI-NET-DCF 
mailto:thomas.g...@swisscom.com>>; 
han...@gredler.at
Cc: lsr@ietf.org; spr...@ietf.org; 
ops...@ietf.org
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Thomas,

I should have been more clear in my email.

The proposal/suggestion is to add the following to the IPFIX MPLS Label type 
identifier registry:

  *   SR Prefix SID
  *   SR Adjacency SID
  *   SR Binding SID
  *   SR BGP Peering SID
  *   

Re: [Lsr] [OPSAWG] draft-tgraf-ipfix-mpls-sr-label-type

[Gyan Mishra]

Hi Thomas

Just a thought to build on what Tianran mentioned.

It almost seems as if IPFIX taking on the role of BGP-LU / PCE  centralized
controller function to to create a SR graph of the topology.  We already
have all the SR topology data in the PCE for path instantiation and
steering.

Do we also really need the data replicated into IPFIX.

The PCE may also be able to do fault isolation and troubleshooting as it
has the topology of the entire SR domain.

Something to consider.  Also gathering flat bits and pieces of information
is  not the same as what is being fed by BGP-LS into the PCE.  So am
wondering what value this will provide with the flat construction of the
network graph.

Gyan

On Sun, Aug 16, 2020 at 11:05 PM Tianran Zhou 
wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi Thomas,
>
>
>
>
>
> I think questions from both Ketan and Gyan on the IE usage are very
> important. The value should be described clearly in the draft. So that
> people now how to implement and use them.
>
>
> Here your replay to Ketan on the mplsTopLabelType is clear to me. You want
> to account the traffic with different IGP distribution, to see if your
> network runs correct.
>
>
> The SrSidType seems more complex.
>
>
> “Since it describes that a particular adjacency is chosen to forward the
> packet instead of a prefix. If IE 89, ForwardingStatus is drop, we
> understand that result of that decision lead to the drop and this enables
>
> to narrow down forwarding issues in segment routing networks more
> efficiently and quickly.”
>
>
> Could you please make this use case more clear joint with IE89?
>
>
> And this case want to justify the value of Adjacency SID. Is there any
> other use cases for accounting other sid types?
>
>
>
>
>
> Thanks,
>
>
> Tianran
>
>
>
>
>
>
>
>
>
> *From:* OPSAWG [mailto:opsawg-boun...@ietf.org]
>
> *On Behalf Of*thomas.g...@swisscom.com
>
>
> *Sent:* Saturday, August 15, 2020 2:01 PM
>
>
> *To:* ket...@cisco.com; han...@gredler.at
>
>
> *Cc:* lsr@ietf.org; spr...@ietf.org; ops...@ietf.org
>
>
> *Subject:* Re: [OPSAWG] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type
>
>
>
>
>
>
>
>
>
> Hi Ketan,
>
>
>
>
>
>
>
> Ø
>
> This helps identification of specific SR-MPLS segment types as well as
> differentiating them from LDP, RSVP-TE, etc.
>
>
>
>
>
> To be precise, the existing MPLS Label Type identifier differentiates from
> LDP, RSVP-TE. Not the new SrSidType IPFIX IE being proposed.
>
>
>
>
>
>
>
> Ø
>
> What value is provided for IPFIX analysis if the SR Prefix SID was being
> signalled via OSPF or ISIS?
>
>
>
>
>
>
> It is important to distinguish between intend and result.
>
>
>
>
>
> If you migrate from one label distribution protocol to another, a network
> operator want's to understand if the data plane is still forwarding packets
> with
>
> the label distribution protocol which needs to be removed or not. IE46
> enables that by looking at the result of the forwarded traffic and not at
> the intend. RFC 8661 section 3,
>
> https://tools.ietf.org/html/rfc8661#section-3,
>
> describes the context.
>
>
>
>
>
>
>
> Ø
>
> What value is provided for IPFIX analysis if it was a Adjacency SID or a
> LAN Adjacency SID?
>
>
>
>
>
> Quote from RFC8402. "Segment Routing (SR) leverages the source routing
> paradigm". Means that not the routing protocol does all the forwarding
> decisions,
>
> the node can change the forwarding by pushing additional labels.. With
> IPFIX SrSidType we are able to cover this dimension in IPFIX. Enabling to
> analyze the result of this decision. The example with " Adjacency SID or a
> LAN Adjacency SID" is not very useful
>
> because the difference of the two is the topology among the adjacency. If
> you compare " Adjacency SID with Prefix SID", that makes much more sense.
> Since it describes that a particular adjacency is chosen to forward the
> packet instead of a prefix. If IE 89,
>
> ForwardingStatus is drop, we understand that result of that decision lead
> to the drop and this enables to narrow down forwarding issues in segment
> routing networks more efficiently and quickly.
>
>
>
>
>
> Ø
>
> am asking for WG to weigh the implementation complexities
>
>
>
>
>
> For the WG and me, I would be important if you can describe more detailed
> what you mean with
>
> implementation complexities. I would like to have a better understanding
> where your fear is coming from. I would appreciate if you could
> differentiate between
>
> MPLS Label Type identifier, IE46, from which label protocol the label was
> coming from and SrSidType which SID type was used..
>
>
>
>
>
>
> Best wishes
>
>
> Thomas
>
>
>
>
>
>
>
>
>
> *From:* Ketan Talaulikar (ketant) 
>
>
>
>
> *Sent:* Saturday, August 15, 2020 7:09 AM
>
>
> *To:* Graf Thomas, INI-NET-DCF ;
>
> han...@gredler.at
>
>
> *Cc:* lsr@ietf.org;
>
> spr...@ietf.org; ops...@ietf.org
>
>
> *Subject:* RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type
>
>
>
>
>
>
>
>
>
> Hi Thomas,
>
>
>
>
>
> I should have been more clear in my email.
>
>
>
>
>
>