Re: [ippm] IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022)

[[e-mail]]

Hi Sue,

In section 3 of RFC 9197, it says "IOAM is focused on "limited domains", as defined in [RFC8799]".
In section 7.1 of draft-ietf-ippm-rfc8321bis, it says "The Alternate Marking Method is an example of a solution limited to a controlled domain [RFC8799]".
So I'm not sure whether the use case you provided is valid or not, anyway, I've responded to Giuseppe that his explanation on the relationship between draft-ietf-ippm-ioam-conf-state and draft-ietf-idr-bgp-ifit-capabilities is acceptable to me.

Cheers,
Xiao Min
------------------Original------------------
From: SusanHares <[e-mail]>
To: 肖敏10093570;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2022年07月08日 23:21
Subject: RE: [ippm]  IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022)
" _ue_custom_node_="true">
Xiao:
Thank you for your continued responses to help me
work through the issues.
The purpose of IBGP (NVE1 to NVE2) is to share information
that will be exported via EBGP.
(IBGP) NVE1---SW1---SW2---SW3---NVE2 (IBGP)---EBGP speaker
The exportation may be information (BGP-LS) or
actionable.  BGP Route Reflectors (RR) may pass this
information between IGP clusters at the IGP border
to keep the information consistent with
Consider NVE1, NVE2, NVE3, NVE4 – all speak IBGP
NVE1 speaks EBGP- with AS-700
NVE4 also speak IBGP with AS-2
------------------RR------------------------------------------------
|                                         |          |                                 |
NVE1-SW1-SW2-SW3-NVE2—NVE3—SW4-SW5-NVE-4
|(domain-1-Flex-algo     | – (domain-2-RSVP-TE)---------|-- AS-2
||        AS-1                                                                            ||
(see page 3 of the draft.)
Hop by hop in the drafts is BGP hop by hop in the draft.
The whole information with RR and BGP-LS is to bring the
Information back to a centralized RR that is co-located
With a centralized manager.
This is a reasonable usage of the BGP-LS technology
to support SRv6 or SR-MPLS.
So, the use case is reasonable for BGP-LS with SR routing.
Are you concerned about the specifics of the draft
rather than the use case?
Have I missed something in your responses?
Sue
From: [e-mail] <[e-mail]>
Sent: Friday, July 8, 2022 5:18 AM
To: Susan Hares <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [ippm] IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022)
Hi Sue,
Please see inline...
Best Regards,
Xiao Min
------------------Original------------------
From: SusanHares <[e-mail]>
To: 肖敏10093570;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2022年07月08日 05:18
Subject: RE: [ippm]  IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022)
" _ue_custom_node_="true">
Xiao:
I’m sorry I missed this email until today.
[XM]>>> That would happen to everyone, never mind :-)
1. on the IFIT versus other IPPM terms.
I will ask the IPPM chairs to help walk through IPPM standard terms.
[XM]>>> That's great. Expect to see an agreement reached among you chairs of the IPPM&IDR WGs.
draft-wang-idr-bgp-ifit-capabilities-05.txt has been accepted, and
will be published as draft-ietf-idr-bgp-ifit-capabilities-00.txt
The authors have been notified that feedback from the IPPM
chairs may require a revision in their draft.
2. On the reference to the draft-ietf-ippm-ioam-conf-state
Are you concerned about interactions between the BGP
process (IBGP) and the insitu OAM process within a IGP domain?
Or are you concerned about the information passed between
AS in the e-BGP process between domains (e.g. AS1 --- AS2)
Interacting with the insitu OAM process?
Or both?
Your comment is a bit vague even with the draft reference.
I need some more details prior to discussing your concerns with the
draft-ietf-idr-bgp-ifit-capabilities author team and the IPPM chairs.
[XM]>>> Let me provide an example to explain my concern and suggestion.
Assume a data center network where IFIT capabilities discovery is needed.
Forwarding path of the IFIT encapsulated data packet is as below.
NVE1---SW1---SW2---SW3---NVE2
Using draft-ietf-ippm-ioam-conf-state, NVE1 can obtain the IFIT capabilities of SW1/SW2/SW3/NVE2 through ICMPv6 Echo Request/Reply.
Using draft-ietf-idr-bgp-ifit-capabilities, NVE1 can obtain the IFIT capabilities of NVE2 through BGP signaling.
What I'm not sure is, why does NVE1 need to obtain the IFIT capabilities of NVE2 through BGP if NVE1 has already obtained them through ICMPv6?
Note that this is just an example. I suggest more general answer to my question is added into draft-ietf-idr-bgp-ifit-capabilities.
Clarity in the defined interactions between insitu OAM and
is important (e.g. some specified interaction or no interaction
cheers, Susan Hares
From: [e-mail] <[e-mail]>
Sent: Thursday, June 30, 2022 11:29 PM
To: Susan Hares <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [ippm] IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022)
Hi Sue,
Please see inline...
Cheers,
Xiao Min
------------------Original------------------
From: SusanHares <[e-mail]>
To: Tianran Zhou <[e-mail]>;肖敏10093570;
Cc: [e-mail] <[e-mail]>;
Date: 2022年06月30日 21:05
Subject: RE: [ippm]  IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022)
" _ue_custom_node_="true">
Xiao Min:
My understanding is that you are concern about the abbreviation (IFIT) rather than the substance of the draft.
[XM]>>> I suggest the authors to use the terms already defined in IPPM.
This BGP draft deals with passing this information between egress and ingress BGP routers
“This document introduces extensions to the Border Gateway Protocol (BGP)
to advertise supported IFIT capabilities of the egress node to the ingress [BGP] node… “
(page 2).
Your comments deal with this technology.
[XM]>>> I suggest the authors to add reference to draft-ietf-ippm-ioam-conf-state and explain the relationship between them.
Thank you,
Sue
From: Tianran Zhou <[e-mail]>
Sent: Wednesday, June 29, 2022 11:46 PM
To: [e-mail]; Susan Hares <[e-mail]>
Cc: [e-mail]
Subject: RE: [ippm] IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022)
I do not see any overlap here.
All the information, the usage and the extended protocol are quite different.
Tianran
-----Original Message-----
From: ippm [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Thursday, June 30, 2022 10:22 AM
To: [e-mail]
Cc: [e-mail]
Subject: Re: [ippm] IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022)
Hi Susan,
Thank you for the response.
Please see inline my comments with [XM]>>>.
Best Regards,
Xiao Min
------------------Original------------------
From: SusanHares <[e-mail]>
To: 肖敏10093570;
Cc: [e-mail] <[e-mail]>;
Date: 2022年06月30日 05:28
Subject: RE: [ippm] IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022) " _ue_custom_node_="true">
Xiao:
Thank you for your feedback regarding this draft.
I need clarification on your feedback.
The introduction of draft-wang-idr-bgp-ifit-capabilities-05.txt
states IFIT is an abbreviation used by their draft as denoted in their abstract:
“This document defines extensions to BGP [RFC4271] to advertise the In-situ Flow Information Telemetry (IFIT) capabilities.”
Since this abbreviation is shared with:
draft-ietf-idr-sr-policy-ifit-03 (ready for WG LC) in their abstract:
“In-situ Flow Information Telemetry
(IFIT) refers to network OAM data plane on-path telemetry techniques, in particular the most popular are In-situ OAM (IOAM) and Alternate Marking.”
Are you objecting to their abbreviation or the terms behind the abbreviation?
[XM]>>> Since I started work in IPPM around 2017, both Alternate Marking and In-situ OAM were already there and I've been used to them. If the IPPM WG decides to introduce a new/second term to scope Alternate Marking and/or In-situ  OAM,  that's  fine to me. However, I don't believe it's the common practice to put a new/second term to IPPM techniques from the outside of IPPM.
2.  Would you please provide additional details on the overlap between draft-wang-idr-bgp-ifit-cpabilities-05.txt and draft-ietf-ippm-ioam-conf-state.
[XM]>>> As I said, the term IFIT brings some confusion to me, in IPPM, Alternate Marking and In-situ OAM are targeted by separate documents. If I understand draft-wang-idr-bgp-ifit-cpabilities-05 correctly, this document covers Capabilities  Discovery  for  both Alternate Marking and In-situ OAM, only edge to edge. As a comparison, draft-ietf-ippm-ioam-conf-state-03 covers Capabilities Discovery for In-situ OAM (if necessary, the same mechanism can be used for Alternate Marking as well), both edge  to edge  and  hop by hop.
Thank you Susan Hares
From: [e-mail] <[e-mail]>
Sent: Wednesday, June 29, 2022 5:06 AM
To: Susan Hares <[e-mail]>
Cc: [e-mail]
Subject: Re: [ippm] IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022) Hi Susan, Thank you for this notice, very helpful.
I have two concerns as follow:
1. As far as I know, iFIT is not a standardized term defined in any IPPM RFC or WG draft, however iFIT includes Alternate Marking and In-situ OAM which both are defined in IPPM. I'm not sure it's appropriate, that looks out of order  to  me.  The  right order IMHO is to define iFIT in IPPM first (if necessary), and then to define protocol extensions (e.g. BGP extensions) to support iFIT.
2. In IPPM there is draft-ietf-ippm-ioam-conf-state that achieves the similar function intended by draft-wang-idr-ifit-capabilities, the two documents looks overlapping to some extent.
Best Regards,
Xiao Min
------------------Original------------------
From: SusanHares <[e-mail]>
To: [e-mail] <[e-mail]>;
Date: 2022年06月24日 23:29
Subject: [ippm] IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022) _______________________________________________
ippm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ippm
Marcus, Tommy and ippm WG:
The IDR WG would like your feedback on two drafts in IDR:
1. draft-ietf-idr-sr-policy-ifit-03.txt – The IDR WG is planning WG LC on this draft in August.
2. draft-wang-idr-ifit-capabilities-05.tt – The IDR WG has consensus on adopting this draft.
Please let us know if you have any concerns regarding these drafts.
We note that these drafts reference:
1) draft-ietf-6man-ipv6-alt-mark
2) draft-ietf-ippm-ioam-data
3) draft-ietf-ippm-ioam-direct-export
4) draft-ietf-ippm-ioam-flags
5) draft-ietf-ippm-ioam-ipv6-options
Please let me know if you have any questions regarding these two drafts.
I am one of the IDR WG co-chairs and the shepherd for these two drafts.
You can reply to this thread or provide information to your WG chairs.
Cheers, Susan Hares
_______________________________________________
ippm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ippm