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

Gyan Mishra <hayabusagsm@gmail.com> Sun, 16 August 2020 20:39 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0E93A1122; Sun, 16 Aug 2020 13:39:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.076
X-Spam-Level:
X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AC_BR_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHAXnsihlBKg; Sun, 16 Aug 2020 13:39:44 -0700 (PDT)
Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 266163A1136; Sun, 16 Aug 2020 13:39:44 -0700 (PDT)
Received: by mail-vk1-xa32.google.com with SMTP id s81so3106402vkb.3; Sun, 16 Aug 2020 13:39:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TmWffxdvbvGn862UXdFqTpSrX1LEC1PmlKXYZTuCLtQ=; b=S9+yQ7ABVt/oWGe1rwJ8fWpQKXBToQrp5rnyz+jTXWKkUdzDPzgp/gP7HMct7fAedC 0jEEdfGfS0eaJ+OVH7UEfOzWlgRVZXFgDRKv/ZUCMt3IB5WY2EskF7O79cJPENJkn+f1 wT1Fu+hGOR+TU2nSYluM4JhmO0G+T+CvqbpS3LM3slNQuEVCvF0j2VLrj2zadJ5qM3Vo Z1JoJ0040dXz2fJMJPo7cXd6tnlNk+7mS/p67Wo/8dfMbcLKfhRLFli4Ny2VNOqGlVQA +mjzoQED6h9UrjG2srpnkwDBAT+6ESaWf8+jHiKQUK9u1jnOy18KtvxTsv8K01ZyZwTQ P2qw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TmWffxdvbvGn862UXdFqTpSrX1LEC1PmlKXYZTuCLtQ=; b=oVnsZtGPr9Dp7F4pLde87wHQETe5lm7nOCjCxjAzHIxAcP3IC/N/9eUnPzFX6uZPrw PEeRdqrdR0cMB7NK2v3UvXVmeNGmEOXXVCNqHmemrSBS75eC9qPpVOLAr7VKzl+Phhb6 5PKvNRzzKBA7WovbnCukjSBR1obHYYXLgp/T5alGC1bDCRpAIuoa8vhC1682yg1GKTCD Gqzg6J72cMthq0kjHy/r4uGl+Avi6uB8DYmSlqcN78scOJLNJlf3NJiHp+ZVv1CVwpyn 4NAHKGUPANJPGL37wdJjyve4Jei/nYhV4B7hkLhdu3plE3WSzyfEMzMuQ5JtkYHeKFJK CVuA==
X-Gm-Message-State: AOAM533HrX+D5JMsDwEwbky2WQUc/cY32rLF5ua16ey+W41yoX2+4ZFm YEGc37ImfI0iYeH4RZdSWFH+lQyOV/jhE5DVt/Y=
X-Google-Smtp-Source: ABdhPJzc6rxhygLhUhwusboMlSdtO4fv9VLrRyPxZblxRDimPnZA6YOOBeTGwnqQ9QYngPVClfupGyP54uLOLyegLxY=
X-Received: by 2002:a1f:1a0e:: with SMTP id a14mr6652600vka.87.1597610382778; Sun, 16 Aug 2020 13:39:42 -0700 (PDT)
MIME-Version: 1.0
References: <1307140725.3423419.1595923900561@ss002890> <44EA00AA-E9D9-4173-9F34-219752DACA5D@gredler.at> <1419364510.2875.1596208917648@ss002890> <MW3PR11MB4570F20CFE2C0E46C8D4B2DEC1400@MW3PR11MB4570.namprd11.prod.outlook.com> <2022615026.3001869.1597464620979@ss002889> <SA0PR11MB45763F383D707E5B6873963DC1410@SA0PR11MB4576.namprd11.prod.outlook.com> <696872714.3003081.1597471334092@ss002889> <CABNhwV0JdK1V17iS8sLLWcnMvoN22SS+gkrmF9E++cheYSnN4A@mail.gmail.com> <1180087721.1311955.1597562009048@ss007564>
In-Reply-To: <1180087721.1311955.1597562009048@ss007564>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sun, 16 Aug 2020 16:39:31 -0400
Message-ID: <CABNhwV0sJtrkddBvuVSp26dE=VNO2NRh9Sqtuj_gOEBettmtbA@mail.gmail.com>
To: Thomas.Graf@swisscom.com
Cc: hannes@gredler.at, ketant@cisco.com, lsr@ietf.org, opsawg@ietf.org, spring@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005ae49e05ad04a7de"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/uhMJ305ELZCaDHkdIcHRDp-_168>
Subject: Re: [Lsr] [OPSAWG] draft-tgraf-ipfix-mpls-sr-label-type
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Aug 2020 20:39:50 -0000

Hi Thomas

Sorry for any misunderstanding.  I am well aware of the origins and history
behind IPFIX and Neflow and use with BGP monitoring.

I was not aware of IE 46 and how that was being leveraged to support SR IGP
extensions sid types.

After  reviewing your IPFIX slides related to IE 46 registry for
mplsTopLabelType and this drafts solution to extend the IE 46 registry with
SR and now requiring new IGP codepoints to be allocated.

You had given an example in the LDP interworking example or others that
with this new IGP codepoint in case of multiple control planes present such
as both LDP and SR that with IPFIX and with the new IGP codepoint
allocations for each IGP type that you can see the forwarding resulting FIB
entry.  I can see that as a benefit for monitoring telemetry

In-line  below addresses complexity of extending IE46 for SR support.

On Sun, Aug 16, 2020 at 3:13 AM <Thomas.Graf@swisscom.com> wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi Gyan,
>
>
>
>
>
> Gyan> IPFIX has been traditionally been used for flow analysis and to that
> end all that was required is support of the data plane encapsulation.  With
> your proposed SR support idea you are really transforming the IPFIX
>
> to be used for not just flow monitoring at that level solely, but now also
> to analyze and troubleshoot data plane forwarding.  That is a considerable
> departure I think from what IPFIX was intended.  I am not sure we want to
> add that layer of complexity into
>
> IPFIX.
>
>
>
>
>
> Thomas> I have seen your feedback to Tarek and was puzzled about your
> remark about data plane encapsulation and IPFIX. I think you have a limited
> picture for what IPFIX has been intended and being used. I do not want
>
> to lecture, but it might be useful to go back to the origins of Netflow
> and IPFIX. At the beginning, the main reason for was to account traffic for
> BGP control-plane dimensions. Such as BGP peer AS, src and dst prefix
> attribute. These helped to account traffic
>
> in shared enviroments. Later also for datacenters. These was and is always
> in conjunction with the encapsulated header metrics of forwarded traffic
> and device dimensions such as ingress interface, egress interface, vrf id
> and vrf name. In order to have a proper
>
> picture about the forwarding plane, and to enable data correlation, key
> fields from other perspectives (control-plane, forwarding-plane, device)
> are necessary to enable data correlation with other protocols such as BMP
> and YANG.
>
>
>
>
>
>
> Thomas> Going back to the initial conversation. Section 7.2 of RFC 5102
>
>
> https://tools.ietf.org/html/rfc5102#section-7.2
>
>
>
>
>
>    For ensuring extensibility of this information, IANA has created a
>
>
>    new registry for MPLS label types and filled it with the initial list
>
>
>    from the description Information Element #46, mplsTopLabelType.
>
>
>
>
>
> Thomas> When IPFIX was specified, it has been defined in mind that other
> MPLS label protocols will be developed in the future. Which is the case
> with RFC 8665, 8666, 8667 and 8669. All adding TLV's to carry segment
> routing
>
> SID's. In the presentation I gave, I showed one of many vendors
> implemented IE46 and showing the wrong value. Event though the label
> protocol was IS-IS SR TLV, the value shown was LDP. This is not acceptable.
> When new protocols are developed, we at IETF must
>
> ensure that they can be properly monitored. With IPFIX we have the proper
> protocol to do that. Even without modifications as section 4 in
> draft-ali-spring-sr-traffic-accounting mentioned:
>
>
>
>
> https://tools.ietf.org/html/draft-ali-spring-sr-traffic-accounting-01#section-4
>
>
>
>
>
> Thomas> You have been referring to complexity. One of the key objectives
> of SR-MPLS was that it does not much change in the MPLS data plane. You
> need to explain on this WG how SR differs from other MPLS label protocols
>
> in terms of RIB/FIB. And then from there *why* an implementation would be
> difficult. That’s the discussion I am looking forward to.
>
>
> Gyan> SR-MPLS reuses the MPLS data plane so from that  perspective is the
> same but how it differs is with SR steering and MSD SID depth with SR-TE
> especially when strict ERO is defined with adjacency SID the label stack is
> expanded.
>

    With MPLS we are label swapping however with SR you are label
stacking.  So let’s say you have an SR-TE path instantiated and using the
strict ERO path with adjacency SIDs defined,  would just the active label
being used in the forwarding plane be the one that IPFIX would be
monitoring versus the entire stack of labels.

> In theory it appears that the IPFIX machinery is in place with IE 46 to
> support SR as what you have proposed in the draft.
>

    As far as vendor compatibility as long as they         support IE 46
they should support SR-MPLS.

I don’t see any issues now as far as complexities to support as the we are
using existing machinery IPFIX IE 46 to extend for SR support.

I think getting feedback from LSR is critical on their thoughts on
complexity and caveats with getting the codepoints assigned.

What about IPFIX  SRv6 support?

Comment on Section 2

   A typical use case scenario is to monitor MPLS control plane
   migrations from LDP to IS-IS or OSPF.  By looking at the MPLS label
   value itself, it is not always clear as to which label protocol it
   belongs, since they could potentially share the same label allocation
   range.  This is the case for IGP-Adjacency SID's and LDP as an
   example.

SR SRGB label range is different then LDP label range.



>
>
> Best wishes
>
>
> Thomas
>
>
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
>
>
>
>
> *Sent:* Saturday, August 15, 2020 9:26 PM
>
>
> *To:* Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>
>
>
> *Cc:* hannes@gredler.at; ketant@cisco.com; lsr@ietf.org; opsawg@ietf.org;
> spring@ietf.org
>
>
> *Subject:* Re: [OPSAWG] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi Thomas
>
>
>
>
>
>
>
>
>
>
>
>
>
> Responses in-line
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Aug 15, 2020 at 2:02 AM <Thomas.Graf@swisscom.com> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 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
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8661%23section-3&data=02%7C01%7CThomas.Graf%40swisscom.com%7C569e273bc05c4e6ea27b08d84151132d%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637331163758926165&sdata=wHBPYkw2k4iUxKMA9OZavfa7X8bO%2BrII7GQ7hhyo1K0%3D&reserved=0>
> ,
>
>
>
>
>
> describes the context.
>
>
>
>
>
>
>
>
>
>
>
> Gyan> IPFIX has been traditionally been used for flow analysis and to that
> end all that was required is support of the data plane encapsulation.  With
> your proposed SR support idea you are really transforming the IPFIX to be
> used for not
>
> just flow monitoring at that level solely, but now also to analyze and
> troubleshoot data plane forwarding.  That is a considerable departure I
> think from what IPFIX was intended.
>
>
>
>
>
>
>
>
>
>
>
>
>
> I am not sure we want to add that layer of complexity into IPFIX.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>    -
>
>    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) <ketant@cisco.com>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Sent:* Saturday, August 15, 2020 7:09 AM
>
>
>
>
>
>
>
>
> *To:* Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>;
>
> hannes@gredler.at
>
>
>
>
>
>
>
>
> *Cc:* lsr@ietf.org;
>
> spring@ietf.org; opsawg@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
>    -
>
>    … and so on
>
>
>
>
>
>
>
>
>
>
>
>
> This helps identification of specific SR-MPLS segment types as well as
> differentiating them from LDP, RSVP-TE, etc.
>
>
>
>
>
>
>
>
>
>
>
> And my questions were:
>
>
>
>
>
>
>
>
>
>
>
>
>
>    1.
>
>    What value is provided for IPFIX analysis if the SR Prefix SID was
>    being signalled via OSPF or ISIS?
>    2.
>
>    What value is provided for IPFIX analysis if it was a Adjacency SID or
>    a LAN Adjacency SID?
>
>
>
>
>
>
>
>
>
>
>
>
> I am asking for WG to weigh the implementation complexities and overheads
> with the proposed details of SR-MPLS segments in IPFIX against the benefit
> (if any)
>
> that they provide for the
>
>
>
>
>
> flow analysis and monitoring.
>
>
>
>
>
>
>
>
>
>
>
> Thanks,
>
>
>
>
>
> Ketan
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:*
>
>
>
>
>
>
>
> Thomas.Graf@swisscom.com <Thomas.Graf@swisscom.com>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Sent:* 15 August 2020 09:40
>
>
>
>
>
>
>
>
> *To:* Ketan Talaulikar (ketant) <ketant@cisco.com>;
>
>
>
>
>
> hannes@gredler.at
>
>
>
>
>
>
>
>
> *Cc:* lsr@ietf.org;
>
>
>
>
>
>
>
> spring@ietf.org; opsawg@ietf.org
>
>
>
>
>
>
>
>
> *Subject:* RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi Ketan,
>
>
>
>
>
>
>
>
>
>
>
> Thank you very much for the review and feedback.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>    -
>
>    What or how much value be there on determining whether a SR Prefix SID
>    was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS
>
>
>
>
>
>    – what matters and is more important is that it is a Prefix SID.
>    Hardly any deployments would be running multiple protocols and learning the
>    same prefix from different IGPs.
>
>
>
>
>
>
>
>
>
>
>
>
> As Jeff already pointed out. Multiple IGP labelling protocols are used  in
> networks when migrations
>
> are ongoing. Usually in a life cycle. Migrating from
>
>
>
>
>
> LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swisscom
> when we first discovered this shortcoming in vendor implementations. The
> key point here, with these additional IPFIX MPLS Label Type identifiers we
> enable the possibility to verify the
>
>
>
>
>
> label protocol migration without taking the label value into the
> consideration.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>    -
>
>    IPFIX may be picking this information from a FIB in some
>    implementation where the protocol does not matter and this information
>
>
>
>
>
>    is not available therein.
>
>
>
>
>
>
>
>
>
>
>
>
> I am not sure if you have seen the presentation in IETF 108 at OPSAWG and
> SPRING.
>
>
>
>
>
>
> https://www.ietf.org/proceedings/108/slides/slides-108-opsawg-export-of-mpls-sr-label-type-information-in-ipfix-00.pdf
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fproceedings%2F108%2Fslides%2Fslides-108-opsawg-export-of-mpls-sr-label-type-information-in-ipfix-00.pdf&data=02%7C01%7CThomas.Graf%40swisscom.com%7C569e273bc05c4e6ea27b08d84151132d%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637331163758926165&sdata=aPDG5Npa0SXTJo06hspotby9nJ3diAINYePD6J8D%2BZ0%3D&reserved=0>
>
>
>
>
>
>
>
>
>
>
>
> Slide 2 shows Cisco as example vendor which implemented IE 46, MPLS Label
> Type identifier. There
>
> is an open ddts where vendor feasibility has been clarified.
>
>
>
>
>
> Ping me off the list when you like to have more details.
>
>
>
>
>
>
>
>
>
>
>
> I do understand your point that not all the vendors are capable to
> implement IE 46.
>
> But that’s not the point about the IPFIX IE registry.
>
>
>
>
>
> The IE registry enables that an IPFIX implementation can refer to the
> right code point. With RFC 5102 the decision has been made that MPLS Label
> Type identifier make sense
>
>
>
>
>
> and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type just extends
> the IE 46 registry with the Segment Routing label protocol code points so
> when OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, the IPFIX
> implementation can point to the right
>
>
>
>
>
> code point.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>    -
>
>    On some nodes, the same Prefix SID may be learnt via both BGP and IGP
>    – what would we use/show?
>
>
>
>
>
>
>
>
>
>
>
>
> In this case the IE 46 shows the label protocol which was used to program
> the FIB.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>    -
>
>
>
>
>
>
>
>    For that table proposal, it is very difficult and in some cases not
>    possible to different between Prefix and Node and Anycast SID. Many of
>    these types are control plane elements and we can
>
>
>
>
>
>    be sure more get added.
>
>
>
>
>
>
>
>
>
>
>
>
> I fully agree. As a network operator its still hard to understand the
> architecture
>
> and constraints within a router. When monitoring capabilities
>
>
>
>
>
> are discussed at IETF, this is the usual topic. What is possible, what
> make sense. By purpose, all available SID types are listed in the draft.
> This with the aim to start the discussion in the working groups what is
> possible what makes sense. I would be interested
>
>
>
>
>
> to get your and also Jeff's feedback.
>
>
>
>
>
>
>
>
>
>
>
> In above mentioned slides I described how TI-LFA application would benefit
> of visibility
>
> in the FIB by showing where Adj-SID was used. This
>
>
>
>
>
> should be a simple example why it make sense not only to look at which
> label protocol was used to forward a particular packet, but also which SID
> type to further understand the intend why this label is being pushed.
>
>
>
>
>
>
>
>
>
>
>
> I hope this makes all sense. Looking forward for reply.
>
>
>
>
>
>
>
>
>
>
>
> Best wishes
>
>
>
>
>
> Thomas
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* Ketan Talaulikar (ketant) <ketant@cisco.com>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Sent:* Friday, August 14, 2020 7:35 PM
>
>
>
>
>
>
>
>
> *To:* Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>;
>
>
>
>
>
> hannes@gredler.at
>
>
>
>
>
>
>
>
> *Cc:* lsr@ietf.org; SPRING WG <spring@ietf.org>
>
>
>
>
>
>
>
>
> *Subject:* RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> < also copying Spring WG for their review/inputs >
>
>
>
>
>
>
>
>
>
>
>
> Hi Thomas/All,
>
>
>
>
>
>
>
>
>
>
>
> I have reviewed the draft and would like to share a different perspective.
>
>
>
>
>
>
>
>
>
>
>
> What or how much value be there on determining whether a SR Prefix SID was
> signalled/programmed on a node via OSPFv2/OSPFv3/ISIS – what matters and is
> more important
>
> is that it is a
>
>
>
>
>
> Prefix SID. Hardly any deployments would be running multiple protocols and
> learning the same prefix from different IGPs. IPFIX may be picking this
> information from a FIB in some implementation where the protocol does not
> matter and this information is not
>
>
>
>
>
> available therein.
>
>
>
>
>
>
>
>
>
>
>
> On some nodes, the same Prefix SID may be learnt via both BGP and IGP –
> what would we use/show?
>
>
>
>
>
>
>
>
>
>
>
> I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID,
> SR BGP Peering SID and so on … for the MPLS Label Type.
>
>
>
>
>
>
>
>
>
>
>
> This also takes away the need for the second table that is being proposed
> to a large extent. For that table proposal, it is very difficult and in
> some cases not
>
> possible to different
>
>
>
>
>
> between Prefix and Node and Anycast SID. Many of these types are control
> plane elements and we can be sure more get added. Is there really much
> value in differentiation between say an Adjacency SID and LAN Adjacency SID?
>
>
>
>
>
>
>
>
>
>
>
> Could we evaluate the implementation overhead and complexity of this level
> of categorization/information in IPFIX against their value in flow analysis
> to perhaps
>
> consider a middle ground?
>
>
>
>
>
>
>
>
>
>
>
> Thanks,
>
>
>
>
>
> Ketan
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* Lsr <lsr-bounces@ietf.org>
>
>
>
>
>
> *On Behalf Of *Thomas.Graf@swisscom.com
>
>
>
>
>
>
>
>
> *Sent:* 31 July 2020 20:52
>
>
>
>
>
>
>
>
> *To:* hannes@gredler.at
>
>
>
>
>
>
>
>
> *Cc:* lsr@ietf.org
>
>
>
>
>
>
>
>
> *Subject:* Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi Hannes,
>
>
>
>
>
>
>
>
>
>
>
> Thanks a lot for the feedback. Yes, makes completely sense. Will take it
> for the
>
> next update...
>
>
>
>
>
>
>
>
>
>
>
> Best Wishes
>
>
>
>
>
> Thomas
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* Hannes Gredler <hannes@gredler.at>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Sent:* Wednesday, July 29, 2020 9:31 AM
>
>
>
>
>
>
>
>
> *To:* Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>
>
>
>
>
>
>
>
>
> *Cc:* lsr@ietf.org
>
>
>
>
>
>
>
>
> *Subject:* Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Thomas,
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> I have one comment/suggestion to Paragraph 4 (IANA Considerations).
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Please add also a code point for BGP Prefix-SID - it’s quite popular in DC
> deployments.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> https://tools..ietf.org/html/rfc8669
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8669&data=02%7C01%7CThomas.Graf%40swisscom.com%7C569e273bc05c4e6ea27b08d84151132d%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637331163758936119&sdata=Fsvq88N0tH7w2ksT50%2FtiB%2BjjSgMiYDczoL0LnrmP1Q%3D&reserved=0>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> thanks,
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> /hannes
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 28.07.2020, at 10:11,
>
>
>
>
>
>
>
> Thomas.Graf@swisscom.com wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Dear lsr,
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> I presented the following draft
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Export of MPLS Segment Routing Label Type Information in IP Flow
> Information Export (IPFIX)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-tgraf-ipfix-mpls-sr-label-type-04&data=02%7C01%7CThomas.Graf%40swisscom.com%7C569e273bc05c4e6ea27b08d84151132d%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637331163758936119&sdata=zZ8aGGT4%2BhALWRePiWWnMSCN%2BwZOqhpjacfiyrQQyQ0%3D&reserved=0>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> at the spring working group at IETF 108 yesterday
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-information-export-ipfix-00.pdf
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fproceedings%2F108%2Fslides%2Fslides-108-spring-ip-flow-information-export-ipfix-00.pdf&data=02%7C01%7CThomas.Graf%40swisscom.com%7C569e273bc05c4e6ea27b08d84151132d%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637331163758936119&sdata=msjazpFiGymlAxYRDGZkAk9JOdbsZsxCV5Pl1j7PUoM%3D&reserved=0>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> and today at OPSAWG where I call for adoption.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> This draft adds additional segment routing code points for in the IANA
> IPFIX registry for IS-IS,
>
> OPSFv2 and OPSF v3 and segment routing SID types to gain
>
>
>
>
>
> further insights into the MPLS-SR forwarding-plane.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> I have been asked to not only gather feedback from spring and opsawg but
> also from lsr and mpls
>
> working groups since these code points are related to link
>
>
>
>
>
> state routing protocols and mpls data plane.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> I am looking forward to your feedback and input.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Best Wishes
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Thomas Graf
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
>
>
>
>
>
>
>
> Lsr mailing list
>
>
>
>
>
>
>
>
> Lsr@ietf.org
>
>
>
>
>
>
>
>
> https://www.ietf.org/mailman/listinfo/lsr
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7CThomas.Graf%40swisscom.com%7C569e273bc05c4e6ea27b08d84151132d%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637331163758946075&sdata=l0BxgILkPzTCw8VkgrGov6W22AQtX4Zs3Wm45QF37vo%3D&reserved=0>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
>
>
>
>
> OPSAWG mailing list
>
>
>
>
>
> OPSAWG@ietf.org
>
>
>
>
>
> https://www.ietf.org/mailman/listinfo/opsawg
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fopsawg&data=02%7C01%7CThomas.Graf%40swisscom.com%7C569e273bc05c4e6ea27b08d84151132d%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637331163758946075&sdata=qUj3CvJgp%2BWiHSyTmF5baL9P2OJ4HGl8cDJihIpV8eE%3D&reserved=0>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=02%7C01%7CThomas.Graf%40swisscom.com%7C569e273bc05c4e6ea27b08d84151132d%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637331163758956033&sdata=Q1hTVdl%2FP5vcDFMFfbwkICQ%2F4uSqUX8ggxwPatqtGM0%3D&reserved=0>
>
>
> *Gyan Mishra*
>
>
> *Network Solutions Architect *
>
>
>
>
>
>
>
>
> *M 301 502-134713101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g> *Silver
> Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
>
>
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD