Subject: Fwd: New Version Notification for draft-previdi-6man-segment-routing-header-07.txt

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 20 Jul 2015 19:07:32 +0000

Hi,

as suggested I resubmitted the SRH draft with a new security section that includes the content of the former SRH-security draft.

At this stage, I'd re-iterate my question: can the WG consider the adoption of draft-previdi-6man-segment-routing-header as WG item ?

Thanks.
s.

Begin forwarded message:
> From: <[email-masked]>
> Subject: New Version Notification for draft-previdi-6man-segment-routing-header-07.txt
> Date: July 20, 2015 9:05:11 PM GMT+02:00
> To: Eric Vyncke <[email-masked]>, Ida Leung <[email-masked]>, Brian Field <[email-masked]>, Stefano Previdi <[email-masked]>, David Lebrun <[email-masked]>, Ebben Aries <[email-masked]>, Eric Vyncke <[email-masked]>, Clarence Filsfils <[email-masked]>, Stefano Previdi <[email-masked]>, Ida Leung <[email-masked]>, David Lebrun <[email-masked]>, "Brian Field" <[email-masked]>, Clarence Filsfils <[email-masked]>, Ebben Aries <[email-masked]>
> 
> 
> A new version of I-D, draft-previdi-6man-segment-routing-header-07.txt
> has been successfully submitted by Stefano Previdi and posted to the
> IETF repository.
> 
> Name:		draft-previdi-6man-segment-routing-header
> Revision:	07
> Title:		IPv6 Segment Routing Header (SRH)
> Document date:	2015-07-20
> Group:		Individual Submission
> Pages:		33
> URL:            https://www.ietf.org/internet-drafts/draft-previdi-6man-segment-routing-header-07.txt
> Status:         https://datatracker.ietf.org/doc/draft-previdi-6man-segment-routing-header/
> Htmlized:       https://tools.ietf.org/html/draft-previdi-6man-segment-routing-header-07
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-previdi-6man-segment-routing-header-07
> 
> 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.
> 
>   Segment Routing 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: Alexandru Petrescu <[email-masked]>
Date: Mon, 20 Jul 2015 21:18:16 +0200

clarification q: what is "NAT Srvc" designating in Figure 4?

Alex

Le 20/07/2015 21:07, Stefano Previdi (sprevidi) a écrit :
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 20 Jul 2015 19:44:00 +0000

> clarification q: what is "NAT Srvc" designating in Figure 4?

it's an illustration showing that a segment is not strictly limited to a routing forwarding instruction but could also be related to a service or application.

s.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 Jul 2015 09:30:35 +0200

Do you mean a Network Address Translation service?  That would be 
qualified as a particular forwarding instruction in addresses are 
substituted.

Or is this wrong?

Alex

Le 20/07/2015 21:44, Stefano Previdi (sprevidi) a écrit :
> it's an illustration showing that a segment is not strictly limited
> to a routing forwarding instruction but could also be related to a
> service or application.
>
> s.
>
>
>>
>> Alex
>>
>>
>>> as suggested I resubmitted the SRH draft with a new security
>>> section that includes the content of the former SRH-security
>>> draft.
>>>
>>> At this stage, I'd re-iterate my question: can the WG consider
>>> the adoption of draft-previdi-6man-segment-routing-header as WG
>>> item ?
>>>
>>> Thanks. s.
>>>
>>>
>>>
>>> Begin forwarded message:
>>>> From: <[email-masked]> Subject: New Version
>>>> Notification for
>>>> draft-previdi-6man-segment-routing-header-07.txt Date: July 20,
>>>> 2015 9:05:11 PM GMT+02:00 To: Eric Vyncke <[email-masked]>,
>>>> Ida Leung <[email-masked]>, Brian Field
>>>> <[email-masked]>, Stefano Previdi
>>>> <[email-masked]>, David Lebrun <[email-masked]>,
>>>> Ebben Aries <[email-masked]>, Eric Vyncke <[email-masked]>,
>>>> Clarence Filsfils <[email-masked]>, Stefano Previdi
>>>> <[email-masked]>, Ida Leung <[email-masked]>,
>>>> David Lebrun <[email-masked]>, "Brian Field"
>>>> <[email-masked]>, Clarence Filsfils
>>>> <[email-masked]>, Ebben Aries <[email-masked]>
>>>>
>>>>
>>>> A new version of I-D,
>>>> draft-previdi-6man-segment-routing-header-07.txt has been
>>>> successfully submitted by Stefano Previdi and posted to the
>>>> IETF repository.
>>>>
>>>> Name:		draft-previdi-6man-segment-routing-header Revision:	07
>>>> Title:		IPv6 Segment Routing Header (SRH) Document date:
>>>> 2015-07-20 Group:		Individual Submission Pages:		33 URL:
>>>> https://www.ietf.org/internet-drafts/draft-previdi-6man-segment-routing-header-07.txt
>>>>
>>>>
Status: 
https://datatracker.ietf.org/doc/draft-previdi-6man-segment-routing-header/
>>>> Htmlized:
>>>> https://tools.ietf.org/html/draft-previdi-6man-segment-routing-header-07
>>>>
>>>>
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-previdi-6man-segment-routing-header-07
>>>>
>>>> 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.
>>>>
>>>> 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
>>>>
>>>
>>> [email-masked] Administrative Requests:
>>> https://www.ietf.org/mailman/listinfo/ipv6
>> IETF IPv6 working group mailing list [email-masked] Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 21 Jul 2015 08:18:36 +0000

On Jul 21, 2015, at 9:30 AM, Alexandru Petrescu <[email-masked]> wrote:

> Do you mean a Network Address Translation service?

put whatever is your preferred service. maybe nat is not the best illustration. Take dpi, webcache, webacc, ...

s.

>  That would be qualified as a particular forwarding instruction in addresses are substituted.
> 
> Or is this wrong?
> 
> Alex
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 Jul 2015 11:21:30 +0200

Content Distribution Networks is an important service in which segment 
routing may be involved.

But NAT should be removed from there.

Alex

Le 21/07/2015 10:18, Stefano Previdi (sprevidi) a écrit :
> put whatever is your preferred service. maybe nat is not the best
> illustration. Take dpi, webcache, webacc, ...
>
> s.
>
>
>>> it's an illustration showing that a segment is not strictly
>>> limited to a routing forwarding instruction but could also be
>>> related to a service or application.
>>>
>>> s.
>>>
>>>
>>>>
>>>> Alex
>>>>
>>>>
>>>>> At this stage, I'd re-iterate my question: can the WG
>>>>> consider the adoption of
>>>>> draft-previdi-6man-segment-routing-header as WG item ?
>>>>>
>>>>> Thanks. s.
>>>>>
>>>>>
>>>>>
>>>>> Begin forwarded message:
>>>>>> draft-previdi-6man-segment-routing-header-07.txt Date: July
>>>>>> 20, 2015 9:05:11 PM GMT+02:00 To: Eric Vyncke
>>>>>> <[email-masked]>, Ida Leung <[email-masked]>,
>>>>>> Brian Field <[email-masked]>, Stefano
>>>>>> Previdi <[email-masked]>, David Lebrun
>>>>>> <[email-masked]>, Ebben Aries <[email-masked]>, Eric
>>>>>> Vyncke <[email-masked]>, Clarence Filsfils
>>>>>> <[email-masked]>, Stefano Previdi <[email-masked]>,
>>>>>> Ida Leung <[email-masked]>, David Lebrun
>>>>>> <[email-masked]>, "Brian Field"
>>>>>> successfully submitted by Stefano Previdi and posted to
>>>>>> the IETF repository.
>>>>>>
>>>>>> Name:		draft-previdi-6man-segment-routing-header Revision:
>>>>>> 07 Title:		IPv6 Segment Routing Header (SRH) Document
>>>>>> date: 2015-07-20 Group:		Individual Submission Pages:		33
>>>>>> URL:
Status: 
Diff: 
>>>>>>
>>>>>> 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
>>>>>> Segment Routing 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
>>>>>>
>>>>>
>>>> IETF IPv6 working group mailing list [email-masked]
>>>> Administrative Requests:

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 21 Jul 2015 09:23:27 +0000

Maybe... but note that in the opetators world there are practical examples where SR is used exactly for that...

s.

-----Original Message-----
From: Alexandru Petrescu [[email-masked]]
Received: Tuesday, 21 Jul 2015, 11:21
To: Stefano Previdi (sprevidi) [[email-masked]]
CC: [email-masked]} [[email-masked]]
Subject: Re: New Version Notification for draft-previdi-6man-segment-routing-header-07.txt - NAT Srvc

Alex

Status:
Diff:

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 Jul 2015 13:02:29 +0200

SR to substitute NAT functionality?  Or SR to complement NAT functionality?

I have not seen NAT IPv6 in the operators world.

And, I dont think we want SR to have same drawbacks as NAT.

Alex

Le 21/07/2015 11:23, Stefano Previdi (sprevidi) a écrit :
> Maybe... but note that in the opetators world there are practical
> examples where SR is used exactly for that...
>
> s.
>
> *From:* Alexandru Petrescu [[email-masked]]
> *Received:* Tuesday, 21 Jul 2015, 11:21
> *To:* Stefano Previdi (sprevidi) [[email-masked]]
> *CC:* [email-masked]} [[email-masked]]
> *Subject:* Re: New Version Notification for
> draft-previdi-6man-segment-routing-header-07.txt - NAT Srvc
>

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 21 Jul 2015 11:30:51 +0000

No. SR is used to steer the packet towards an application /service instance.

s.

-----Original Message-----
From: Alexandru Petrescu [[email-masked]]
Received: Tuesday, 21 Jul 2015, 13:02
To: Stefano Previdi (sprevidi) [[email-masked]]
CC: [email-masked] [[email-masked]]
Subject: Re: New Version Notification for draft-previdi-6man-segment-routing-header-07.txt - NAT Srvc

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 Jul 2015 16:38:45 +0200

I just read the Illustrative Example section.

Is there an SDN controller which uses SR?  The one I use (OpenDaylight) 
controls switches, not routers.

Alex

Le 21/07/2015 13:30, Stefano Previdi (sprevidi) a écrit :
> *Received:* Tuesday, 21 Jul 2015, 13:02
> *CC:* [email-masked] [[email-masked]]

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Jul 2015 20:01:16 +0200

The draft says:
> With SR-IPv6 the Node-SID is an IPv6 prefix that the operator
> configured on the node and that is used as the node
> identifier.[...]The Node-SID is in fact the IPv6 address of the
> node.

I think it should not say it is a prefix, because it is not.  It is an 
address.

And the SRH does not contain prefixes, but addresses (there is no prefix 
length).

FWIW.

Alex

Le 21/07/2015 16:38, Alexandru Petrescu a écrit :
> Is there an SDN controller which uses SR?  The one I use
> (OpenDaylight) controls switches, not routers.
>
> Alex
>
>> -----Original Message----- *From:* Alexandru Petrescu
>> [[email-masked]] *Received:* Tuesday, 21 Jul 2015,
>> 13:02 *To:* Stefano Previdi (sprevidi) [[email-masked]] *CC:*
>> [email-masked] [[email-masked]] *Subject:* Re: New Version
>> Notification for draft-previdi-6man-segment-routing-header-07.txt -
>> NAT Srvc
>>
>>> Maybe... but note that in the opetators world there are
>>> practical examples where SR is used exactly for that...
>>>
>>> s.
>>>
>>> -----Original Message----- *From:* Alexandru Petrescu
>>> [[email-masked]] *Received:* Tuesday, 21 Jul 2015,
>>> 11:21 *To:* Stefano Previdi (sprevidi) [[email-masked]] *CC:*
>>> [email-masked]} [[email-masked]] *Subject:* Re: New Version
>>> Notification for draft-previdi-6man-segment-routing-header-07.txt
>>> - NAT Srvc
>>>
>>> Content Distribution Networks is an important service in which
>>> segment routing may be involved.
>>>
>>>> put whatever is your preferred service. maybe nat is not the
>>>> best illustration. Take dpi, webcache, webacc, ...
>>>>
>>>> s.
>>>>
>>>>
>>>>> That would be qualified as a particular forwarding
>>>>> instruction in addresses are substituted.
>>>>>
>>>>> Or is this wrong?
>>>>>
>>>>> Alex
>>>>>
>>>>>> it's an illustration showing that a segment is not
>>>>>> strictly limited to a routing forwarding instruction but
>>>>>> could also be related to a service or application.
>>>>>>
>>>>>> s.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>>
>>>>>>>> as suggested I resubmitted the SRH draft with a new
>>>>>>>> security section that includes the content of the
>>>>>>>> former SRH-security draft.
>>>>>>>>
>>>>>>>>> From: <[email-masked]> Subject: New
>>>>>>>>> Version Notification for
>>>>>>>>> draft-previdi-6man-segment-routing-header-07.txt
>>>>>>>>> Date: July 20, 2015 9:05:11 PM GMT+02:00 To: Eric
>>>>>>>>> Vyncke <[email-masked]>, Ida Leung
>>>>>>>>> <[email-masked]>, Brian Field
>>>>>>>>> <[email-masked]>, David Lebrun
>>>>>>>>> <[email-masked]>, Ebben Aries
>>>>>>>>> <[email-masked]>, Eric Vyncke <[email-masked]>,
>>>>>>>>> Clarence Filsfils <[email-masked]>, Stefano
>>>>>>>>> Previdi <[email-masked]>, Ida Leung
>>>>>>>>> <[email-masked]>, David Lebrun
>>>>>>>>> draft-previdi-6man-segment-routing-header-07.txt has
>>>>>>>>> been successfully submitted by Stefano Previdi and
>>>>>>>>> posted to the IETF repository.
>>>>>>>>>
>>>>>>>>> Name:
>>>>>>>>> draft-previdi-6man-segment-routing-header Revision:
>>>>>>>>> 07 Title:                IPv6 Segment Routing Header
>>>>>>>>> (SRH) Document date: 2015-07-20 Group:
>>>>>>>>> Individual Submission Pages:            33 URL:
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> Segment Routing 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: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Jul 2015 20:02:46 +0200

I just learned at BnB that there is an implementation of SRH, and it is 
demonstrated.

It is assigning a full IPv6 address to a movie.  A /64 subnet will 
accommodate many movies.

CDN networks may take advantage of this.

Alex

Le 21/07/2015 16:38, Alexandru Petrescu a écrit :
>>>>>>>>> Revision:

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Jul 2015 20:08:08 +0200

The draft says:
>    The ingress node (e.g.: the host in the home network) requests the
>    SRH from a control system (e.g.: an SDN controller) which delivers
>    the SRH with its HMAC signature on it.

Are we sure the Host in the home network can share a key with the
routers in the ISP network? I dont share any keys with my ADSL operator.

If this hypothetical key is shared with the ISP, can the SRH contain
addresses outside of the ISP? This would still be insecure.

Is the HMAC optional value in the SRH the same as the one in AH? Or
nothing to do? I suggest make it same.

Alex

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Thu, 23 Jul 2015 20:58:13 +0000

Alexandru,
> I just learned at BnB that there is an implementation of SRH, and it is demonstrated.

Actually there multiple implementations of SR-IPv6 (Cisco, Comcast, Ecole
Polytechnique, UCLouvain) and interoperability has been demonstrated during previous BnB event at IETF; please refer to slide 4 from the deck presented by Stefano during the 6man meeting.  

Cheers
Roberta

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: Thursday, July 23, 2015 8:03 PM
To: [email-masked]
Subject: Re: New Version Notification for draft-previdi-6man-segment-routing-header-07.txt - implementation

I just learned at BnB that there is an implementation of SRH, and it is demonstrated.

It is assigning a full IPv6 address to a movie.  A /64 subnet will accommodate many movies.

Alex

Le 21/07/2015 16:38, Alexandru Petrescu a écrit :
>>>>>>>>> Brian Field <[email-masked]>, Stefano Previdi 
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> of submission until the htmlized version and diff are