Subject: [spring] SR-IPv6 drafts

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 6 Mar 2014 10:21:35 +0000

All,

here below you'll find the pointers to:
draft-martin-spring-segment-routing-ipv6-use-cases-00
draft-previdi-6man-segment-routing-header-00

that have been submitted today.

Any comment, contribution, suggestion, flames,... are welcome.

s.

Begin forwarded message:
> A new version of I-D, draft-martin-spring-segment-routing-ipv6-use-cases-00.txt
> has been successfully submitted by Roberta Maglione and posted to the
> IETF repository.
> 
> Name:		draft-martin-spring-segment-routing-ipv6-use-cases
> Revision:	00
> Title:		IPv6 Segment Routing Use Cases
> Document date:	2014-03-06
> Group:		Individual Submission
> Pages:		12
> URL:            http://www.ietf.org/internet-drafts/draft-martin-spring-segment-routing-ipv6-use-cases-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-martin-spring-segment-routing-ipv6-use-cases/
> Htmlized:       http://tools.ietf.org/html/draft-martin-spring-segment-routing-ipv6-use-cases-00
> 
> 
> Abstract:
>   Segment Routing (SR) leverages the source routing paradigm.  A node
>   steers a packet through a controlled set of instructions, called
>   segments, by prepending the packet with an SR header.  A segment can
>   represent any instruction, topological or service-based.  A segment
>   can have a local semantic to an SR node or global within an SR
>   domain.  SR allows to enforce a flow through any topological path and
>   service chain while maintaining per-flow state only at the ingress
>   node to the SR domain.
> 
>   The objective of this document is to illustrate some use cases that
>   would benefit from an IPv6 Segment Routing data-plane architecture.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat
> 

Begin forwarded message:
> A new version of I-D, draft-previdi-6man-segment-routing-header-00.txt
> has been successfully submitted by Stefano Previdi and posted to the
> IETF repository.
> 
> Name:		draft-previdi-6man-segment-routing-header
> Revision:	00
> Title:		IPv6 Segment Routing Header (SRH)
> Document date:	2014-03-05
> Group:		Individual Submission
> Pages:		22
> URL:            http://www.ietf.org/internet-drafts/draft-previdi-6man-segment-routing-header-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-previdi-6man-segment-routing-header/
> Htmlized:       http://tools.ietf.org/html/draft-previdi-6man-segment-routing-header-00
> 
> 
> Abstract:
>   Segment Routing (SR) allows a node to steer a packet through a
>   controlled set of instructions, called segments, by prepending a SR
>   header to the packet.  A segment can represent any instruction,
>   topological or service-based.  SR allows to enforce a flow through
>   any path (topological, or application/service based) while
>   maintaining per-flow state only at the ingress node to the SR domain.
> 
>   The Segment Routing architecture can be applied to the IPv6 data
>   plane with the addition of a new type of Routing Extension Header.
>   This draft describes the Segment Routing Extension Header Type and
>   how it is used by SR capable nodes.
> 
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 6 Mar 2014 09:19:57 -0500

Stefano,

Thanks for posting this!

Alia

(And sorry about forwarding it again - a hazard of reading email from most
recent backwards!)

On Thu, Mar 6, 2014 at 5:21 AM, Stefano Previdi (sprevidi) <
[email-masked]> wrote:

> > A new version of I-D,
> draft-martin-spring-segment-routing-ipv6-use-cases-00.txt
> > URL:
> http://www.ietf.org/internet-drafts/draft-martin-spring-segment-routing-ipv6-use-cases-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-martin-spring-segment-routing-ipv6-use-cases/
> > Htmlized:
> http://tools.ietf.org/html/draft-martin-spring-segment-routing-ipv6-use-cases-00
> >
> >
> > Abstract:
> > URL:
> http://www.ietf.org/internet-drafts/draft-previdi-6man-segment-routing-header-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-previdi-6man-segment-routing-header/
> > Htmlized:
> http://tools.ietf.org/html/draft-previdi-6man-segment-routing-header-00
> >
> >
> > Abstract:
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: AshwoodsmithPeter <[email-masked]>
Date: Thu, 6 Mar 2014 16:24:13 +0000

Hey Stefano,

If I extrapolate the link overhead from the SP data that I got and presented at the last IETF the 4 x larger per segment overhead for this header translates into a 24% increase in link utilization for the PW mobile backhaul link data that I have and a 7% approx overhead for the remainder of the SP links (assuming only 3 hops). This is compared to a 7% and 2% overhead respectively for MPLS (also 3 hops).

http://www.ietf.org/proceedings/88/slides/slides-88-spring-4.pdf  (last chart).

I am not sure what kinds of overheads are acceptable but I suspect that 5% is 'sort of acceptable' but getting into the high teens is 'less so'.

We may need to consider some kind of compression. For example it would be possible to store shorter or even variable sized segment id's. If for example the header included a segment id size field the segment list could even be smaller than the MPLS segment list in some circumstances. Of course then you'd need to indirect to get the IPV6 addresses.

Cheers,

Peter

From: spring [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Thursday, March 06, 2014 9:20 AM
To: Stefano Previdi (sprevidi)
Cc: [email-masked]
Subject: Re: [spring] SR-IPv6 drafts

Stefano,

Thanks for posting this!
Alia
(And sorry about forwarding it again - a hazard of reading email from most recent backwards!)

On Thu, Mar 6, 2014 at 5:21 AM, Stefano Previdi (sprevidi) <[email-masked]<mailto:[email-masked]>> wrote:
All,

s.

Begin forwarded message:
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
> The IETF Secretariat
>

Begin forwarded message:
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
> The IETF Secretariat
>

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Mach Chen <[email-masked]>
Date: Thu, 6 Mar 2014 16:48:23 +0000

Hi Stefano and Peter,

I have the same concern as Peter here, 128-bit segment SID seems too large. IMHO, we could use a shorter SID (32-bit SID) , just as originally proposed in the SR architecture draft, and then using a mapping mechanisms to translate the 32-bit SID to an IPv6 address at each SR-capable router.

Best regards,
Mach

From: spring [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Friday, March 07, 2014 12:24 AM
To: Stefano Previdi (sprevidi)
Cc: [email-masked]
Subject: Re: [spring] SR-IPv6 drafts

Hey Stefano,

Cheers,

Peter

Cc: [email-masked]<mailto:[email-masked]>

Stefano,

Thanks for posting this!
Alia

s.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 6 Mar 2014 17:19:48 +0000

On Mar 6, 2014, at 5:24 PM, AshwoodsmithPeter wrote:
> I am not sure what kinds of overheads are acceptable but I suspect that 5% is ‘sort of acceptable’ but getting into the high teens is ‘less so’.
>  
> We may need to consider some kind of compression. For example it would be possible to store shorter or even variable sized segment id’s. If for example the header included a segment id size field the segment list could even be smaller than the MPLS segment list in some circumstances. Of course then you’d need to indirect to get the IPV6 addresses.

variable size segment identifiers is an appealing solution but
it comes with other challenges.

However, I agree with you, there are efficient compression techniques 
we could use, especially if the scope of a SR-IPv6 deployment is 
within an operator infrastructure (i.e.: single domain). One being the 
use of a common prefix within the domain and allocated to SR and you'd
specify only the host bits (as SID).

Keeping in mind that using v6 address requires no specific signaling 
for SR (prefixes are advertised anyway).

Something certainly worth to investigate.

s.

> On Thu, Mar 6, 2014 at 5:21 AM, Stefano Previdi (sprevidi) <[email-masked]> wrote:
> All,
>

---

From: AshwoodsmithPeter <[email-masked]>
Date: Thu, 6 Mar 2014 18:49:54 +0000

Hey Stefano, 

Apart from mapping challenges what would be the other challenges caused by a single field in the header that gave the size of the elements in the segment list? It seems to me from a data path perspective it's pretty much the same as MPLS, i.e. indirect through a table to get what you really need. Or are you thinking about control plane challenges?

BTW I very much like the approach to validation of the segment list. 

Peter

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]] 
Sent: Thursday, March 06, 2014 12:20 PM
To: AshwoodsmithPeter
Cc: [email-masked]
Subject: Re: [spring] SR-IPv6 drafts

> We may need to consider some kind of compression. For example it would be possible to store shorter or even variable sized segment id's. If for example the header included a segment id size field t…

variable size segment identifiers is an appealing solution but it comes with other challenges.

However, I agree with you, there are efficient compression techniques we could use, especially if the scope of a SR-IPv6 deployment is within an operator infrastructure (i.e.: single domain). One being the use of a common prefix within the domain and allocated to SR and you'd specify only the host bits (as SID).

Keeping in mind that using v6 address requires no specific signaling for SR (prefixes are advertised anyway).

s.

> > has been successfully submitted by Roberta Maglione and posted to 
> > the IETF repository.
> >
> > 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.
> >
> > The IETF Secretariat
> >
> 
> 
> 
> Begin forwarded message:
> > A new version of I-D, 
> > draft-previdi-6man-segment-routing-header-00.txt
> > 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.
> >
> > The IETF Secretariat
> >
>

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 6 Mar 2014 20:19:59 +0000

Hi Peter,

On Mar 6, 2014, at 7:49 PM, AshwoodsmithPeter wrote:
> Hey Stefano, 
> 
> Apart from mapping challenges what would be the other challenges caused by a single field in the header that gave the size of the elements in the segment list?

I misunderstood you, sorry. I thought you referred to a scheme where 
each element of the segment list could have its own length (we 
explored that). If it's just a matter of a few bits telling you what 
size to expect in the segment list (i.e.: all elements have the same 
size), then it's definitely much easier.

> It seems to me from a data path perspective it's pretty much the same as MPLS, i.e. indirect through a table to get what you really need. Or are you thinking about control plane challenges?

I agree. The "Next Segment" tells where you look at. No big deal.

> BTW I very much like the approach to validation of the segment list. 

Thanks.
s.

---

From: AshwoodsmithPeter <[email-masked]>
Date: Thu, 6 Mar 2014 20:42:48 +0000

Hey Stefano,

Yeah we played with a variable sized encoding too, it's of course tricky to process it quickly. 

Correct, I was referring to just a vector[N] of elements of size [M], so you just need N and M in the header.

Since there are a small finite number of values of M that we care about the encoding can be very simple. For example I imagine {8,16,32,48,64,..128} would likely be a fairly complete set so we only need ~four bits to encode 'M' in the header. 

Something along those lines would give very compact encodings for small networks and be flexible to 'just the right size' for bigger networks and is of course fairly simple to implement quickly in hardware.

Cheers,

Peter

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]] 
Sent: Thursday, March 06, 2014 3:20 PM
To: AshwoodsmithPeter
Cc: [email-masked]
Subject: Re: [spring] SR-IPv6 drafts

Hi Peter,

> Apart from mapping challenges what would be the other challenges caused by a single field in the header that gave the size of the elements in the segment list?

I misunderstood you, sorry. I thought you referred to a scheme where each element of the segment list could have its own length (we explored that). If it's just a matter of a few bits telling you what size to expect in the segment list (i.e.: all elements have the same size), then it's definitely much easier.

Thanks.
s.

>>> domain.  SR allows to enforce a flow through any topological path 
>>> and  service chain while maintaining per-flow state only at the 
>>> ingress  node to the SR domain.
>>>

---

From: "Leddy, John" <[email-masked]>
Date: Thu, 6 Mar 2014 22:09:05 +0000

On the %overhead that is acceptable, my thinking is that where we are
stuck with 1500 byte MTU¹s (access/home), if an SR path was generated it
could be tokenized.

I¹m assuming when the full SID list needs to be put in the header, it is
possible to aggregate the data into a larger MTU packet within the core.

So you may have higher overhead on small data packets (that aren¹t a
significant amount of traffic), but you could be much more efficient with
large data packets which make up the majority of traffic (i.e..video).

John Leddy

On 3/6/14, 1:49 PM, "AshwoodsmithPeter" <[email-masked]>
wrote:

>Hey Stefano, 
>
>Apart from mapping challenges what would be the other challenges caused
>by a single field in the header that gave the size of the elements in the
>segment list? It seems to me from a data path perspective it's pretty
>much the same as MPLS, i.e. indirect through a table to get what you
>really need. Or are you thinking about control plane challenges?
>
>> If I extrapolate the link overhead from the SP data that I got and
>>presented at the last IETF the 4 x larger per segment overhead for this
>>header translates into a 24% increase in link utilization for the PW
>>mobile backhaul link data that I have and a 7% approx overhead for the
>>remainder of the SP links (assuming only 3 hops). This is compared to a
>>7% and 2% overhead respectively for MPLS (also 3 hops).
>> I am not sure what kinds of overheads are acceptable but I suspect that
>>5% is 'sort of acceptable' but getting into the high teens is 'less so'.
>>  
>> We may need to consider some kind of compression. For example it would
>>be possible to store shorter or even variable sized segment id's. If for
>>example the header included a segment id size field the segment list
>>could even be smaller than the MPLS segment list in some circumstances.
>>Of course then you'd need to indirect to get the IPV6 addresses.
>
>
>However, I agree with you, there are efficient compression techniques we
>could use, especially if the scope of a SR-IPv6 deployment is within an
>operator infrastructure (i.e.: single domain). One being the use of a
>common prefix within the domain and allocated to SR and you'd specify
>only the host bits (as SID).
>
>>and

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 7 Mar 2014 13:45:49 +0000

> Yeah we played with a variable sized encoding too, it's of course tricky to process it quickly. 

we swam in the same swamp...

> Something along those lines would give very compact encodings for small networks and be flexible to 'just the right size' for bigger networks and is of course fairly simple to implement quickly in…

Alternatively, you could also use the Routing Header Type as a 
multiplexor and fine different headers for different SID formats.

Still the appealing advantage of using addresses is to avoid 
signaling. If you advertise SIDs you need to signal them. Not a big 
deal if you think at the routing layer but the application layer 
has a different perspective.

Thanks.
s.

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 17 Mar 2014 16:49:36 +0100

hi stefano,

thanks for submitting the document(s).
had a look at 'draft-previdi-6man-segment-routing-header' and
i have concerns about section 4.2.2 - specifically:

---
4.2.2.  Adjacency-SID

   The Adjacency-SID identifies a given interface.  In the SR
   architecture a node may advertise one or more Adj-SIDs allocated to a
   given interface so to force the forwarding of the packet (when
   received with that particular Adj-SID) into the interface, regardless
   the routing entry for the packet destination.  The same is defined
   for SR-IPv6: a node may advertise a given IPv6 prefix which is
   associated to the SR semantic of "send out the packet to the
   interface this prefix is allocated to".  Here also, the SID is in
   fact the IPv6 prefix.
---

my interpretation of the *changed* 'Adjacency-SID' semantics above is that
it is not possible any longer to do 'strict explicit routing' like we used to
do in the MPLS incarnation of SR.

i.e.

in SR-MPLS an 'adjacency-SID' represents a forwarding action that will drop
traffic at a specific neighbor using a specific link - no matter what.

in SR-IPv6 an 'adjacency-SID' represents a forwarding action that will drop
traffic at a specific neighbor using *the most specific IP6 hop-by-hop* forwarding path.
(to spoil the party - consider injecting a more specific route for the remote-end of the link)

may i ask the reasoning for giving up strict explicit routing in the SR-IPv6 dataplane ?
my understanding of one of the values that SR does bring is 'strict explicit routing'
and as such i am worried about consistency between the two data planes;

playing a bit devils advocate: one could argue that you can build the same
(loose source routing plus indicator where a packet does came from) using
nested IP tunnels ...

/hannes

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 17 Mar 2014 15:58:14 +0000

Hi Hannes,

> and as such i am worried about consistency between the two data planes;

you're right and the text needs to be changed. 

The adj-sid/ipv6 address must be used in order to forward the packet 
onto the link, no matter what routing says. 

After all, ipv6 has defined bits in the address as "interface identifier" 
so, also there, we have a natural v6 property for the adj-sid.

s.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 17 Mar 2014 20:30:55 +0000

On 3/18/14 2:49 AM, "Hannes Gredler" <[email-masked]> wrote:

>i have concerns about section 4.2.2

Hi!

Thanks for starting a discussion on this draft.

Please keep in mind that this specific draft is targeted at 6man; it is
great that spring is being cc'd, but the discussion should really happen
in 6man.

Thanks!

Alvaro.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 18 Mar 2014 04:23:31 +0000

On 3/18/14 7:30 AM, "Alvaro Retana (aretana)" <[email-masked]> wrote:

Hi!

I received a couple of comments related to what I wrote below..

>great that spring is being cc'd, but the discussion should really happen

..so I want to clarify.

It is great that the discussion about this draft (and any other for that
matter) is occurring on the list!  However, this draft is targeted at 6man
-- that WG will have to make any decisions around it.  The more
information 6man has about the draft itself, the requirements, any
concerns, etc. the better the decision they will be able to make, so
please make sure that they are also part of the discussion.

The point that I tried to make above was not about moving the discussion
elsewhere and not including spring.  Quite the opposite: please make sure
that spring is cc'd when the related drafts are discussed in other WG
lists.  That will keep everyone in sync and will avoid the need to
potentially have discussions twice.

Just a quick reminder (this is from a message I sent to the list on
March/6):

=====
As was discussed in yesterday's meeting, the RTG ADs have provided
guidance about spring-related drafts in other WGs.  In short, other WGs
may adopt the drafts as long as (1) they are discussed in spring as well,
(2) WGLC takes place in both the adopting WG and spring, and (3) the WGLC
takes place after spring has adopted an architecture and corresponding use
case.
=====

I realize that 6man is not in the RTG area, but the general principle of
discussing the drafts in both the adopting WG and spring still applies.

Thanks!

Alvaro.

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 18 Mar 2014 22:08:07 +0000

Stefano,

IPv4 has loose and strict source routing options. RFC 791 defines their semantics as follows:

 [Strict] "This option is a strict source route because the gateway or host
        IP must send the datagram directly to the next address in the
        source route through only the directly connected network
        indicated in the next address to reach the next gateway or host"
        specified in the route.

 [Loose] "This option is a loose source route because the gateway or host
        IP is allowed to use any route of any number of other
        intermediate gateways to reach the next address in the route."

According to RFC 2460, "The Routing header is used by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a packet's destination.  This function is very similar to IPv4's Loose Source and Record Route option."

IPv6 never had anything like a strict source routing option. If you want a strict source routing semantic, you should consider the following:

- Updating RFC 2460. The above quoted text will need to be changed
- Adding a flag to the SRH that indicates whether strict or loose source routing is intended
- Specifying which address types are allowed in the segment list when loose source routing is specified (global unicast? ULA? LLA?)
- Specifying which address types are allowed in the segment list when strict source routing is specified (global unicast? ULA? LLA?)

I don't think that the interface identifier bits of the IPv6 address will help much. Recall that the nodes in a routing header represent "intermediate nodes to be "visited" on the way to a packet's destination", not outbound interfaces. 

                                                     Ron

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Stefano Previdi (sprevidi)
Sent: Monday, March 17, 2014 4:58 PM
To: Hannes Gredler
Cc: [email-masked]; Clarence Filsfils (cfilsfil)
Subject: Re: [spring] SR-IPv6 drafts / strict explicit routing concerns

Hi Hannes,

On Mar 17, 2014, at 4:49 PM, Hannes Gredler wrote:
> had a look at 'draft-previdi-6man-segment-routing-header' and i have 
> concerns about section 4.2.2 - specifically:
> 
> ---
> 4.2.2.  Adjacency-SID
> 
> my interpretation of the *changed* 'Adjacency-SID' semantics above is 
> that it is not possible any longer to do 'strict explicit routing' 
> like we used to do in the MPLS incarnation of SR.
> 
> i.e.
> 
> in SR-MPLS an 'adjacency-SID' represents a forwarding action that will 
> drop traffic at a specific neighbor using a specific link - no matter what.
> 
> in SR-IPv6 an 'adjacency-SID' represents a forwarding action that will 
> drop traffic at a specific neighbor using *the most specific IP6 hop-by-hop* forwarding path.

The adj-sid/ipv6 address must be used in order to forward the packet onto the link, no matter what routing says. 

s.

> playing a bit devils advocate: one could argue that you can build the 
> same (loose source routing plus indicator where a packet does came 
> from) using nested IP tunnels ...

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 18 Mar 2014 23:20:34 +0100

Ron,

> Recall that the nodes in a routing header represent "intermediate
> nodes to be "visited" on the way to a packet's destination", not
> outbound interfaces.

Please observe that nothing prevents you to insert your peer's interface
address (for example advertised as passive into IGP) into routing's header
and remove it just before it is advertised outside of the domain.

That way effectively and in line with RFC 2460 you will only use
"intermediate nodes" yet achieve well the requirement of lookup less
forwarding via an exit ASBR.

Best regards,
R.

On Tue, Mar 18, 2014 at 11:08 PM, Ronald Bonica <[email-masked]> wrote:

> According to RFC 2460, "The Routing header is used by an IPv6 source to
> list one or more intermediate nodes to be "visited" on the way to a
> packet's destination.  This function is very similar to IPv4's Loose Source
> and Record Route option."
>
> IPv6 never had anything like a strict source routing option. If you want a
> strict source routing semantic, you should consider the following:
>
> - Specifying which address types are allowed in the segment list when
> loose source routing is specified (global unicast? ULA? LLA?)
> - Specifying which address types are allowed in the segment list when
> strict source routing is specified (global unicast? ULA? LLA?)
>
> I don't think that the interface identifier bits of the IPv6 address will
> help much. Recall that the nodes in a routing header represent
> "intermediate nodes to be "visited" on the way to a packet's destination",
> not outbound interfaces.
>
>                                                      Ron
>
>
>
> ....

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 19 Mar 2014 08:37:11 +0000

Robert,

We may be taking past one another. In your message below, which of the following did you mean:

-          You can insert the peer's interface address (i.e., 128 bits) into the SRH

-          You can insert the peer's interface identifier (i.e., less than 128 bits, as defined in Section 2.5 of RFC 4291) into the SRH

I believe that Stephano and I are talking identifiers, not interface addresses. Is that also what you are talking about?

                                                         Ron

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, March 18, 2014 11:21 PM
To: Ronald Bonica
Cc: Stefano Previdi (sprevidi); Hannes Gredler; [email-masked]; Clarence Filsfils (cfilsfil)
Subject: Re: [spring] SR-IPv6 drafts / strict explicit routing concerns

Ron,

> nodes to be "visited" on the way to a packet's destination", not

Please observe that nothing prevents you to insert your peer's interface address (for example advertised as passive into IGP) into routing's header and remove it just before it is advertised outside of the domain.

That way effectively and in line with RFC 2460 you will only use "intermediate nodes" yet achieve well the requirement of lookup less forwarding via an exit ASBR.

Best regards,
R.

On Tue, Mar 18, 2014 at 11:08 PM, Ronald Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Stefano,

                                                     Ron

-----Original Message-----
From: spring [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Stefano Previdi (sprevidi)
Sent: Monday, March 17, 2014 4:58 PM
To: Hannes Gredler
Cc: [email-masked]<mailto:[email-masked]>; Clarence Filsfils (cfilsfil)
Subject: Re: [spring] SR-IPv6 drafts / strict explicit routing concerns

Hi Hannes,
....

s.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 19 Mar 2014 08:58:03 +0000

Ron,

thanks for the info, I have to admit I'm not very familiar with rfc791 ;-)

>From a practical perspective I see the following options:
1. advertise, in the IGP, a prefix with the semantic "forward to the link 
   this prefix is assigned to". Very close to what Robert suggested. 
2. advertise a flag in the existing IGP advertisement of the prefix giving 
   the same semantic as above.

Now, this will also incur an update of the initial paragraph of section 4 
(claiming no additional advertisement is needed). Not a big deal imho.

s.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 19 Mar 2014 10:01:02 +0100

Hello Ron,

You captured the difference correctly.

I am talking about using peer's interface address (or for that matter even
local address if this is p2p link) rather then an identifier.

Maybe terminology needs to be sorted out better in the SR spec.

Best regards,
R.

On Wed, Mar 19, 2014 at 9:37 AM, Ronald Bonica <[email-masked]> wrote:

> -          You can insert the peer's interface identifier (i.e., less
> than 128 bits, as defined in Section 2.5 of RFC 4291) into the SRH
>
>
>
> I believe that Stephano and I are talking identifiers, not interface
> addresses. Is that also what you are talking about?
>
>
>
>                                                          Ron
>
>
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Tuesday, March 18, 2014 11:21 PM
> *To:* Ronald Bonica
> *Cc:* Stefano Previdi (sprevidi); Hannes Gredler; [email-masked];
> Clarence Filsfils (cfilsfil)
>
> *Subject:* Re: [spring] SR-IPv6 drafts / strict explicit routing concerns
>
>
>
> Ron,
>
>
>

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 19 Mar 2014 09:22:40 +0000

Stephano,

I'm glad to see that we both remember rfc 791 ;-)

But I think that we are talking past one another. AFAIKS, Hannes' original comment concerned the forwarding plane. It can be restated as follows:

Assume that an SR-aware node receives a packet. The packet's DA is local to the node, so the nodes examines the IPv6 extension header chain. The IPv6 extension header chain contains an SRH and the next segment on the SRH is reachable. However, the next segment is not directly connected. It is reachable through an intermediate node.

If strict source routing semantics are to be enforced, the node should discard the packet. If loose source routing semantics are to be enforced, the node should forward the packet through the intermediate node. By looking at the packet, how does the IPv6 forwarder know whether to enforce strict or loose source routing semantics?

Here, I assume that SPRING/IPv6 supports both strict and loose source routing semantics, as does SPRING/MPLS. 

                                               Ron

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]] 
Sent: Wednesday, March 19, 2014 9:58 AM
To: Ronald Bonica
Cc: Hannes Gredler; [email-masked]; Clarence Filsfils (cfilsfil)
Subject: Re: [spring] SR-IPv6 drafts / strict explicit routing concerns

Ron,

Now, this will also incur an update of the initial paragraph of section 4 (claiming no additional advertisement is needed). Not a big deal imho.

s.

On Mar 18, 2014, at 11:08 PM, Ronald Bonica wrote:
>> in SR-MPLS an 'adjacency-SID' represents a forwarding action that 
>> will drop traffic at a specific neighbor using a specific link - no matter what.
>> 
>> in SR-IPv6 an 'adjacency-SID' represents a forwarding action that 
>> will drop traffic at a specific neighbor using *the most specific IP6 hop-by-hop* forwarding path.
>>>> segments, by prepending the packet with an SR header.  A segment 
>>>> can represent any instruction, topological or service-based.  A 
>>>> segment can have a local semantic to an SR node or global within an 
>>>> SR domain.  SR allows to enforce a flow through any topological 
>>>> path and service chain while maintaining per-flow state only at the 
>>>> has been successfully submitted by Stefano Previdi and posted to 
>>>> the IETF repository.
>>>>

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 19 Mar 2014 09:34:09 +0000

Robert,

If we are talking about interface addresses (128 bits), my original question remains unanswered. How does the IPv6 forwarding plane know whether to enforce strict or loose source routing semantics?

However, you do bring up another interesting question. Do you really want to include link-local addresses in the segment list? You clearly can't do this when loose source routing semantics are enforced. It might not even be a good idea with strict source routing. This is because a node might have two neighbors, attached through different interfaces, that coincidentally (or not so coincidentally) have the same link-local address.

                                                                                                     Ron

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, March 19, 2014 10:01 AM
To: Ronald Bonica
Cc: Stefano Previdi (sprevidi); Hannes Gredler; [email-masked]; Clarence Filsfils (cfilsfil)
Subject: Re: [spring] SR-IPv6 drafts / strict explicit routing concerns

Hello Ron,

I am talking about using peer's interface address (or for that matter even local address if this is p2p link) rather then an identifier.

Best regards,
R.

On Wed, Mar 19, 2014 at 9:37 AM, Ronald Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

                                                         Ron

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Tuesday, March 18, 2014 11:21 PM
To: Ronald Bonica
Cc: Stefano Previdi (sprevidi); Hannes Gredler; [email-masked]<mailto:[email-masked]>; Clarence Filsfils (cfilsfil)

Ron,

Best regards,
R.

                                                     Ron

-----Original Message-----
From: spring [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Stefano Previdi (sprevidi)
Sent: Monday, March 17, 2014 4:58 PM
To: Hannes Gredler
Cc: [email-masked]<mailto:[email-masked]>; Clarence Filsfils (cfilsfil)
Subject: Re: [spring] SR-IPv6 drafts / strict explicit routing concerns

Hi Hannes,
....

s.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 19 Mar 2014 09:37:46 +0000

> If strict source routing semantics are to be enforced, the node should discard the packet. If loose source routing semantics are to be enforced, the node should forward the packet through the inter…

ok, now I see your point. Sorry for being slow.

The behavior is determined by the SID. Each node advertises its SIDs.
Each SID is associated with a semantic (strict or loose). In SR-MPLS you 
advertise labels as:
. Prefix/Node-SIDs: these have the "loose" semantic.
. Adjacency-SIDs: these have the "strict" semantic.

In SR-IPv6 we do the same:
. IPv6 prefix: "loose" semantic.
. IPv6 prefix with a (new) flag: "strict" semantic.

Example: 
. NodeA and NodeB are connected through interface X which has prefix P
. NodeA and NodeB advertise prefix P with a flag (in SR subTLV) stating
  the "strict" semantic is used if such prefix is found in the segment 
  list as active segment.
. Any node in the network can now send a packet with following segment 
  list:
	. NodeA-loopback-address
	. prefix-P
  The packet will first arrive (loose) in NodeA which will examine the 
  next segment and find prefix-P. The semantic of prefix-P bing "forward 
  to the interface this prefix is allocated to" NodeA will forward the 
  packet accordingly (strict).

Robert suggested mostly the same thing by advertising the host address of 
your directly connected neighbor.

> Here, I assume that SPRING/IPv6 supports both strict and loose source routing semantics, as does SPRING/MPLS. 

aboslutely.

s.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 19 Mar 2014 10:41:38 +0100

Hi Ron,

If I carry IP address which is my peer's interface and the length is 128
bits by definition it is pretty strict routing, no ?

I assume we are talking about exit from domain. So the addresses on the
link and de-facto your EBGP peering addresses. As such those are the
addresses used for BGP next hops (if no next-hop-self is set). Are
link-local addressed used in such scenario ?

Many thx,
R.

On Wed, Mar 19, 2014 at 10:34 AM, Ronald Bonica <[email-masked]> wrote:

>  Robert,
>
>
>
> If we are talking about interface addresses (128 bits), my original
> question remains unanswered. How does the IPv6 forwarding plane know
> whether to enforce strict or loose source routing semantics?
>
>
>
> However, you do bring up another interesting question. Do you really want
> to include link-local addresses in the segment list? You clearly can't do
> this when loose source routing semantics are enforced. It might not even be
> a good idea with strict source routing. This is because a node might have
> two neighbors, attached through different interfaces, that coincidentally
> (or not so coincidentally) have the same link-local address.
>
>
>
>
> Ron
>
>
>
>
>
> *Sent:* Wednesday, March 19, 2014 10:01 AM
>
> *To:* Ronald Bonica

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 21 Mar 2014 20:58:06 +0000

Stephano,

You're not being slow, I am. 

If I understand what you are saying, the strict/loose semantic isn't explicitly encoded anywhere in the SRH. However, it is inferred from the SID. The FIB entry for the SID includes a new attribute that determines whether source routing to this SID is loose or strict. Do I have this much right?

If so, are any other new attributes included in the FIB entry? For example, is the keying material required to authenticate the MAC also included?

                                        Ron

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]] 
Sent: Wednesday, March 19, 2014 10:38 AM
To: Ronald Bonica
Cc: Hannes Gredler; [email-masked]; Clarence Filsfils (cfilsfil)
Subject: Re: [spring] SR-IPv6 drafts / strict explicit routing concerns

The behavior is determined by the SID. Each node advertises its SIDs.
Each SID is associated with a semantic (strict or loose). In SR-MPLS you advertise labels as:
. Prefix/Node-SIDs: these have the "loose" semantic.
. Adjacency-SIDs: these have the "strict" semantic.

Example: 
. NodeA and NodeB are connected through interface X which has prefix P . NodeA and NodeB advertise prefix P with a flag (in SR subTLV) stating

Robert suggested mostly the same thing by advertising the host address of your directly connected neighbor.

aboslutely.

s.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 21 Mar 2014 22:23:08 +0000

On Mar 21, 2014, at 9:58 PM, Ronald Bonica wrote:
> If I understand what you are saying, the strict/loose semantic isn't explicitly encoded anywhere in the SRH. However, it is inferred from the SID.

yes.

> The FIB entry for the SID includes a new attribute that determines whether source routing to this SID is loose or strict. Do I have this much right?

I don't think the fib needs to know anything about loose or strict.

the router does:
.advertise in isis/ospf a SID assigned to an interface: the adj-sid 
.create a fib entry for that sid. The fib "outgoing interface" is the 
  interface the adj-sid is assigned to.

when a packet is received with an active sid being the adj-sid, it is 
forwarded to the interface of the fib entry. The result is that the 
adj-sid allows you to forward to an interface regardless your shortest 
path tree.

s.