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

[Susan Hares <[e-mail]>]

Xiao:

Perhaps you mean more than just abbreviation (wording) in your comments.   Perhaps you are concerned regarding whether our BGP examples fit the limited domains example.   BGP review looks at a wide variety of limited domains as well as full Internet deployment of BGP features.   I’ve provided you a list based on RFC8799 below and my review criteria.

This email exchange is part of the IDR WG’s normal process to do cross-Area WG checking.  IDR Shepherds review for both technology interaction, clarity of text, implementation experience, and security.  IDR has a policy of requiring “running code” before standardizing as proposed standard RFC.

Does the ippm WG process work in the same way?
Do you have implementations of the specifications draft-ietf-idr-bgp-ifit-capabilities refers to?

This has been a delightfully active discussion on IPPM specifications.

Sue


IDR Reviews the networks
===========================================
From RFC8799 the following are called out in section 4:


1. Differentiated services (item 1)  - If DiffServ is orchestrated across an AS boundary

2. Integrated services (item 2) – If IntServ is orchestrated across an AS Boundary.

3.   Network function virtualization.

4.   Service Function Chaining (SFC).

 5. FAST (firewall and Service Tickets)

(BGP is used in DDoS attacks to distribute flow filter specifications via

BGP Flow specifications for firewalls.   Whether this becomes

the (FAST) environment described in RFC8799 depends on one’s viewpoint)



6.   Data Center Network Virtualization Overlays.

7.   Segment Routing.

8.   Autonomic Networking.

9. Homenet – possible, but not normal.

(The BGP protocol exchange information between autonomous systems.

A home network could be considered an AS for some management or filter,

But the home network protocols standardization (babel) is focus on the

Intra-domain case.)


10.   Creative uses of IPv6 features.
 [e.g. flow label, extension headers, SRv6, … ]

11.  Deterministic Networking (DetNet).

12.  Provisioning Domains – BGP-LS and SR fall within this concept for routing nodes.

13. Address scoping – IDR and BESS delay with BGP VPNs + scoping



IDR also checks for (see section 3 of RFC8799)



  8. Delay Tolerant networks
  9.   "Traditional" enterprise and campus networks, which may be
        spread over many kilometers and over multiple separate sites,
        with multiple connections to the Internet.



   11.  Managed wide-area networks run by service providers for

        enterprise services such as Layer 2 (Ethernet, etc.) point-to-

        point pseudowires, multipoint Layer 2 Ethernet VPNs using

        Virtual Private LAN Service (VPLS) or Ethernet VPN (EVPN), and

        Layer 3 IP VPNs.



   12.  Data centers and hosting centers, or distributed services acting

        as such centers.



   13.  Content Delivery Networks (CDNs), comprising distributed data

        centers and the paths between them, spanning thousands of

        kilometers, with numerous connections to the Internet.



   14.  Massive Web Service Provider Networks.



IDR Checks the following applications if document specifies inter-domain

(Multiple AS situation)



a. small office network

b. home network

b. vehicle network

c.  supervisory/data acquisition networks

d. sensor networks

e. IoT

f. Constrained networks



I have personally seen proposals in these cases (a-f).





What IDR Reviews:

--------------------------

1. IDR authors “generally” include the expectations of

deployment within the introduction, security, and manageability sections.



I review the security section to see their expectations, and

we ask the security directorate to review for these expectations.



 2.  IDR shepherds try to cross review with other WG drafts that

     mention technology from another WG within Routing (e.g. BESS, Spring)

     or in an another Area



3.  IDR shepherds ask for early review by directorates in

     Other areas (Internet, Security, Operations).



From: [e-mail] <[e-mail]>
Sent: Monday, July 11, 2022 3:51 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, 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 exa
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzU0YjJjNjkxYzdkM2IwMDRkNzk1ZmMwZjhmMzdiZTkxLzE2NTc1MjY3ODQuNjc=#key=4ccc75e0c02bf83ca94d03287edac055>  FAQ<https://www.inky.com/banner-faq>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>


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]<mailto:[e-mail]>>

To: 肖敏10093570;

Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[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]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>

Sent: Friday, July 8, 2022 5:18 AM

To: Susan Hares <[e-mail]<mailto:[e-mail]>>

Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>>

To: 肖敏10093570;

Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[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]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>

Sent: Thursday, June 30, 2022 11:29 PM

To: Susan Hares <[e-mail]<mailto:[e-mail]>>

Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>>

To: Tianran Zhou <[e-mail]<mailto:[e-mail]>>;肖敏10093570;

Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[e-mail]>>

Sent: Wednesday, June 29, 2022 11:46 PM

To: [e-mail]<mailto:[e-mail]>; Susan Hares <[e-mail]<mailto:[e-mail]>>

Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>

Sent: Thursday, June 30, 2022 10:22 AM

To: [e-mail]<mailto:[e-mail]>

Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>>

To: 肖敏10093570;

Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>

Sent: Wednesday, June 29, 2022 5:06 AM

To: Susan Hares <[e-mail]<mailto:[e-mail]>>

Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>>

To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/ippm<https://shared.outlook.inky.com/link?domain=www.ietf.org&t=h.eJxNjE0OgyAYBa9iWDd8gALqyqsgP5VUwAjGxqZ3r-y6ffNmPujYVzQ2aCllyyPAeZ7Y2-Jw2p8QlF-DirD6XHx0Cfy2BfRo0Ksq0Zb7RAnvxUAZ5EXtNk_RXAvWKQDvZqZvoqVpZ0I6IwfuNHG9a-VsBwpUcMmZkH2HhaxVW6tvrxIOPrLpKraGsI4Vmgr_pu8P3r45Hg.MEQCIDFIYK0OYwIQQNdsrZvedjS_gFzNLoxOup0JQi_XyxTaAiA-x3mYcxnP0YauyB3EQV3t1LNI265mdGDho8gwgtapsw>

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]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/ippm<https://shared.outlook.inky.com/link?domain=www.ietf.org&t=h.eJxNjE0OgyAYBa9iWDd8gALqyqsgP5VUwAjGxqZ3r-y6ffNmPujYVzQ2aCllyyPAeZ7Y2-Jw2p8QlF-DirD6XHx0Cfy2BfRo0Ksq0Zb7RAnvxUAZ5EXtNk_RXAvWKQDvZqZvoqVpZ0I6IwfuNHG9a-VsBwpUcMmZkH2HhaxVW6tvrxIOPrLpKraGsI4Vmgr_pu8P3r45Hg.MEQCIDFIYK0OYwIQQNdsrZvedjS_gFzNLoxOup0JQi_XyxTaAiA-x3mYcxnP0YauyB3EQV3t1LNI265mdGDho8gwgtapsw>