Hi Joel, Inline [PC].
Thanks, Pablo. From: "jmh.direct" <[email protected]> Date: Tuesday, 17 July 2018 at 15:19 To: "Pablo Camarillo (pcamaril)" <[email protected]>, "Joel M. Halpern" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [spring] Transit SIDs Just to confirm, the entire set of behaviors in section 5 are configured behaviors triggered by configured local policy? They are wats to apply segment routing, but are not themselves. represented or advertised as SIDs? [PC]: Indeed. None of the behaviors described in section 5 are SIDs. [PC]: Behaviors 5.2-5.7 are triggered by means of https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-01#section-8. All bullets except the first one (binding SID, which corresponds to End.B6.*). If that is what you are trying to get at with the text there, please rewrite it. Maybe describe the whole,section as an I for national use case? [PC]: Thanks for the feedback. We will consider adding some clarifications on section 5 for the next revision of this document. Maybe also state explicitly that all SIDs are END SIDs. The notation you have chosen makes them look like a SID type. [PC]: If you mean that all SIDs should begin with End.*, then yes, we could have this notation clearly identified. Yours, Joel Yours, Koel Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone -------- Original message -------- From: "Pablo Camarillo (pcamaril)" <[email protected]> Date: 7/17/18 14:55 (GMT-05:00) To: "Joel M. Halpern" <[email protected]>, [email protected] Subject: Re: [spring] Transit SIDs Joel, There is no such thing as a Transit SID. The functions that can be associated with a SID are described in section 4. All these functions are Endpoints functions, whose processing is only triggered by having the destination S registered as a local SID at node N. Section 5 describes the transit behaviours. These behaviours -which are not segments-, are behaviours on transit routers that neither inspect the SRH nor process it. Section 5.1 references RFC8200 on the fact that transit routers MUST NOT inspect or process the SRH. Sections 5.2-5.7 define the transit behaviours that allow steering any incoming traffic into an SR policy. As an example, section 5.4 defines T.Encaps, which states a transit router can steer incoming traffic into an SR policy. As a result, the incoming packet is encapsulated into a new IPv6 header an SRH containing the SIDs of the SR policy. (further details in 5.4). This behavior is triggered based on a local policy -i.e. it is not an SR SID what triggers T.Encaps-. In your example of section 5.2, this is exactly the same. The T.Insert behavior is triggered based on a local policy. B2 is not an SRv6 SID. Thanks, Pablo. On 17/07/2018, 08:00, "Joel M. Halpern" <[email protected]> wrote: I have read the text you quote. That text, which should as you say cause no SR processing in node N, is the exact text which introduces %.1 and 5.2. 5.2 for example is all about node N inserting a new SRH based
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
