Re: [spring] FW: I-D Action: draft-ietf-spring-srv6-network-programming-03.txt

["Pablo Camarillo (pcamaril)" <[e-mail]>]

Inline.

Cheers,
Pablo.

From: li zhenqiang <[e-mail]>
Date: Thursday, 17 October 2019 at 08:43
To: "Pablo Camarillo (pcamaril)" <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: draft-ietf-spring-srv6-network-programming <[e-mail]>
Subject: Re: Re: [spring] FW: I-D Action: draft-ietf-spring-srv6-network-programming-03.txt
Resent from: <[e-mail]>
Resent to: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Resent date: Thursday, 17 October 2019 at 08:43

Hi Pablo,

Till now I don't think a convicing example or even a correct example is provided for the flavors. If no valid use case, why do we create the building blocks?
Why do you say that the examples are not correct? The use-cases have been described in detail. The illustrations are correct. You have not provided any technical concern.
Can you please say why this is “not valid”? Up to now you have not provided any fact, technical concern or reasoning why these are not valid.

Could you please tell me some detail of the case for an SR-host using USD or USP? I am sorry I can not imagine it.
I have never said that USD is related to an SR-host. For USD see this: https://mailarchive.ietf.org/arch/msg/spring/YCIGjvgPDwSibW2BjX7aXDLUQMc

Regarding USP:
As said in the previous email, one such use-cases is a SR-host, where you have SRv6 offloading in a SmartNIC. The SmartNIC does the USP processing, removes the SRH and passes the packet to the linux kernel with the IPv6 header, the other extension headers, and the payload.
There are two SmartNIC vendors supporting SRv6 offloading today.

Are you sure node 3 is the penultimate segment rather than the destination of SID B:3:C4:: in the example listed in section 2.8.1 of srv6-net-pgm-illustration?
I sent another email on your other parallel thread describing it.  https://mailarchive.ietf.org/arch/msg/spring/C22XRhpYpBNBEegERvuIiX06aAo


I am sorry your answer to my question 2 is also difficult to understand.
The "correct" in your answer means that NH in the outer IPv6 header needs to be updated to ENH in EH when a node behaves PSP or USP?
Yes.

or the NH in the outer IPv6 header does not need to be updated just as srv6-network-programming dfaft states in the current version?
This is incorrect. The NET-PGM draft does not state such a thing.

Best Regards,
Zhenqiang Li
________________________________
[e-mail]

From: Pablo Camarillo (pcamaril)<mailto:[e-mail]>
Date: 2019-10-16 00:42
To: li zhenqiang<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
CC: draft-ietf-spring-srv6-network-programming<mailto:[e-mail]>
Subject: Re: [spring] FW: I-D Action: draft-ietf-spring-srv6-network-programming-03.txt
Li,

Inline.

Thanks,
Pablo.

From: li zhenqiang <[e-mail]>
Date: Friday, 11 October 2019 at 03:58
To: "Pablo Camarillo (pcamaril)" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: draft-ietf-spring-srv6-network-programming <[e-mail]>
Subject: Re: Re: [spring] FW: I-D Action: draft-ietf-spring-srv6-network-programming-03.txt
Resent from: <[e-mail]>
Resent to: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Resent date: Friday, 11 October 2019 at 03:58

Hi Pablo,

Would you please explain the benifts of the flavors? Why do you want to do so, not just you can do so.

It’s a question about use-cases and defining building blocks for those use-cases. As such, the flavors are one such building block: they can be enabled or disabled individually at the SR Endpoint; and the SR Headend, upon computation of the SR policy might choose to use the SID with a particular flavor support or not.
A vendor might decide to support it or not; an operator might decide to enable it or not based on his use-case; and -since they are signaled by the IGP-, an SR Headend takes this into account when computing the SR policy.

For USP and USD, when we only use encapsulation, in which situation the destination only do USP, but not decapsulating the outer header?
One example is the case of an SR-host.

Two more questions:
1. draft-ietf-spring-srv6-network-programming says the PSP, USP and USD flavors are variants of the End, End.X and End.T behaviors. But the example illustrated in NET-PGM Section 2.8.1 is DT4.
The End.X behavior with PSP is executed in node 3. Please re-read the paragraph that starts with “When 3 receives the packet, ...”

2. The instructions for PSP and USP are just pop the SRH, don't we need to update the NH in the outer header accordingly? for exmaple, SRH is inserted when encapsulating a packet at an ingress node, and only SRH is inserted, the NH of the outer IPv6 header is SRH, and the NH in the SRH is the upper protocol(the type of the original packet). When the SRH is poped in this example, the NH of the outer header is still SRH, don't we need to update it?
Yes, this is correct.

Best Regards,
Zhenqiang Li
________________________________
[e-mail]

From: Pablo Camarillo (pcamaril)<mailto:[e-mail]>
Date: 2019-10-08 15:02
To: li zhenqiang<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
CC: draft-ietf-spring-srv6-network-programming<mailto:[e-mail]>
Subject: Re: [spring] FW: I-D Action: draft-ietf-spring-srv6-network-programming-03.txt
Zhenqiang, Ron,

The PSP/USP/USD flavors are not -and have never been- related to SRH insertion.
One example for the PSP behavior is the first use-case that Wang described in his email. This same use-case is also captured in the companion illustrations document for NET-PGM Section 2.8.1. [1] together with a detailed packet flow.

Note also that the example that I provided in my previous email is for the USP flavor, which is one of the two that you are asking for. The decapsulation can only be achieved with the USD flavor which is different.

I believe that the technical aspects associated with PSP/USP have been addressed.

Cheers,
Pablo.

[1] https://tools.ietf.org/html/draft-filsfils-spring-srv6-net-pgm-illustration-01#section-2.8.1


From: li zhenqiang <[e-mail]>
Date: Saturday, 28 September 2019 at 17:15
To: "Pablo Camarillo (pcamaril)" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: draft-ietf-spring-srv6-network-programming <[e-mail]>
Subject: Re: Re: [spring] FW: I-D Action: draft-ietf-spring-srv6-network-programming-03.txt

Hello Pablo,

Without SRH insertion, PSP and USP are not needed. The example you give is decapsulation, not SRH pop.
I can not imagine the scenario that will use PSP or USP without SRH insertion. We need illustration to keep them in the draft.

Best Regards,
Zhenqiang Li
________________________________
[e-mail]

From: Pablo Camarillo (pcamaril)<mailto:[e-mail]>
Date: 2019-09-27 19:13
To: li zhenqiang<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
CC: draft-ietf-spring-srv6-network-programming<mailto:[e-mail]>
Subject: Re: [spring] FW: I-D Action: draft-ietf-spring-srv6-network-programming-03.txt
Hi Zhenqiang,

Can you clarify what is the issue with the PSP and USP flavors and how it is related to SRH insertion?

For example USP flavor removes the SRH at the last segment (the final destination of the IP packet), before proceeding with the upper layer header processing.

Cheers,
Pablo.

From: li zhenqiang <[e-mail]>
Date: Friday, 27 September 2019 at 10:41
To: "Pablo Camarillo (pcamaril)" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: draft-ietf-spring-srv6-network-programming <[e-mail]>
Subject: Re: [spring] FW: I-D Action: draft-ietf-spring-srv6-network-programming-03.txt

Hi Pablo and all,

Thank the authors for their efforts and quick reponse to the discussion in the list.
Since the SRH insertion parts are now removed from the base srv6 network programming draft, are the PSP and USP flavors appropriate to stay here? They do the SRH POP action.

Best Regards,
Zhenqiang Li
________________________________
[e-mail]

From: Pablo Camarillo (pcamaril)<mailto:[e-mail]>
Date: 2019-09-25 02:30
To: [e-mail]<mailto:[e-mail]>
CC: [e-mail]<mailto:[e-mail]>
Subject: [spring] FW: I-D Action: draft-ietf-spring-srv6-network-programming-03.txt
Hi all,

We have just posted the split of SRv6 Network Programming.
The SR endpoint and transit behaviors that perform SRH insertion are now under a new individual draft (draft-filsfils-spring-srv6-net-pgm-insertion). This revision does not contain any other update.

As mentioned last week, throughout the rest of the week we will push another update with a few functional updates (e.g. NH=59).

Thank you,
Pablo (on behalf of the authors).


-----Original Message-----
From: spring <[e-mail]> on behalf of "[e-mail]" <[e-mail]>
Reply to: "[e-mail]" <[e-mail]>
Date: Tuesday, 24 September 2019 at 20:23
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-03.txt


    A New Internet-Draft is available from the on-line Internet-Drafts directories.
    This draft is a work item of the Source Packet Routing in Networking WG of the IETF.

            Title           : SRv6 Network Programming
            Authors         : Clarence Filsfils
                              Pablo Camarillo Garvia
                              John Leddy
                              Daniel Voyer
                              Satoru Matsushima
                              Zhenbin Li
    Filename        : draft-ietf-spring-srv6-network-programming-03.txt
    Pages           : 42
    Date            : 2019-09-24

    Abstract:
       This document describes the SRv6 network programming concept and its
       most basic functions.



    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/

    There are also htmlized versions available at:
    https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-03
    https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-03

    A diff from the previous version is available at:
    https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-srv6-network-programming-03


    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org.

    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp.ietf.org/internet-drafts/

    _______________________________________________
    spring mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/spring


_______________________________________________
spring mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/spring