Subject: [spring] Transit SIDs

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 16 Jul 2018 14:45:18 -0400

To ampilfy my question, the text in section 5.1 reads:
    if a node N receives a packet (A, S2)(S3, S2, S1;
    SL=2) and S2 is neither a local address nor a local SID of N

Which clearly reads as describing a case which according to the segment 
routing header (and the 8200 rules) where the neither the SID nor the 
SRH will be processed by node N.

Yours,
Joel

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 17 Jul 2018 11:24:21 +0000

Hi Joel,

Thank you for posting your question on the mailer.

I believe you have missed the second part of that same sentence:

As per [RFC8200], if a node N receives a packet (A, S2)(S3, S2, S1;

   SL=2) and S2 is neither a local address nor a local SID of N then N

   forwards the packet without inspecting the SRH.

Cheers,

Pablo

On 16/07/2018, 14:45, "spring on behalf of Joel M. Halpern" <[email-masked] on behalf of [email-masked]> wrote:

    Yours,

    Joel

    _______________________________________________

    spring mailing list

    [email-masked]

    https://www.ietf.org/mailman/listinfo/spring

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 17 Jul 2018 08:00:25 -0400

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 on a Transit SID B2.  WHich is 
not a local address of N nor a SID of N.

I have no idea what SID in section 5 is a Transit SID, or how it can 
actually trigger the desired behavior in nodes which, as you say, ignore 
the SID.

I presume that the transit SID has to actually be associated with the 
node N.  But the texxt does not tell me how.

Yours,
Joel

On 7/17/18 7:24 AM, Pablo Camarillo (pcamaril) wrote:
>     SL=2) and S2 is neither a local address nor a local SID of N *then N*
> 
> *   forwards the packet without inspecting the SRH*.
> 
> Cheers,
> 
> Pablo
> 
> On 16/07/2018, 14:45, "spring on behalf of Joel M. Halpern" 
> <[email-masked] on behalf of [email-masked]> wrote:
>

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 17 Jul 2018 18:55:37 +0000

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-masked]> wrote:

    
    
    Yours,
    Joel

---

From: "jmh.direct" <[email-masked]>
Date: Tue, 17 Jul 2018 15:19:03 -0400

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?
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?
Maybe also state explicitly that all SIDs are END SIDs.
The notation you have chosen makes them look like a SID type.
Yours,Joel
Yours,Koel

Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone
-------- Original message --------From: "Pablo Camarillo (pcamaril)" <[email-masked]> Date: 7/17/18  14:55  (GMT-05:00) To: "Joel M. Halpern" <[email-masked]>, [email-masked] Subject: Re: [spring] Transit SIDs 
Joel,

Thanks,
Pablo.

    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

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 17 Jul 2018 19:45:21 +0000

Hi Joel,

Inline [PC].

Thanks,
Pablo.

From: "jmh.direct" <[email-masked]>
Date: Tuesday, 17 July 2018 at 15:19
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] Transit 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.*).

[PC]: Thanks for the feedback. We will consider adding some clarifications on section 5 for the next revision of this document.

[PC]: If you mean that all SIDs should begin with End.*, then yes, we could have this notation clearly identified.

Yours,
Joel

Yours,
Koel

-------- Original message --------
From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: 7/17/18 14:55 (GMT-05:00)
To: "Joel M. Halpern" <[email-masked]>, [email-masked]
Subject: Re: [spring] Transit SIDs

Joel,

Thanks,
Pablo.