Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-11.txt>

["Stefano Previdi (IETF)" <[e-mail]>]

Brian,

I agree with you. The SRH draft is still focused to what it has been from
day one: the definition of the segment routing header in all its fields and
tlv's and with the basic algorithm describing what to do with the header.

Many of the ongoing discussions are related to the network programming and
header insertion drafts. I believe that these discussions should we moved
in their specific contexts.

Thanks.

s.

On Tue, Apr 17, 2018, 6:21 AM Brian E Carpenter <[e-mail]>
wrote:

> On 17/04/2018 11:23, Voyer, Daniel wrote:
> ....
> >     2) In order to reduce the degree to which SRv6 extends the IPv6
> Addressing Architecture, the document should represent service-based
> instructions as Destination Options
> > [DV] This seems to be another attempt to tell an operator what they may
> use an IPv6 address for.  You are or course free to put whatever you wish
> in a destination option and parse its TLVs.  As any other implementation is
> free to use IPv6 address they own for whatever purpose they choose.
>
> As a point of information, IPv6 prefixes are not owned. They were
> originally delegated
> to IANA under the terms of RFC1881 (an IAB document): "Delegation of
> address space
> by the IANA is not irrevocable." This doesn't in itself directly affect
> your point,
> but IPv6 delegations are not transfers of ownership; they are more like
> leases.
>
> As to whether address bits should be used for purposes other than
> addressing,
> that's a whole other discussion. Personally I suggest keeping that
> discussion
> out of the present draft, which means not duplicating material from
> spring-srv6-network-programming. At the moment there seems to be quite a
> bit
> of overlapping text, and that will cause problems later. I don't see
> that any of that discussion is needed in the normative definition of
> the SRH. Actually it makes it confusing for the reader - when I look again
> at the description of the End or End.X functions, they really tie the
> reader up in broader aspects of segment routing rather than help to
> clarify the meaning of the header considered on its own. You could define
> the meaning of "segments left" without mentioning the SRH Functions
> concept at all.
>
> (I may be slightly disagreeing with Ron here, but I think we should
> keep the 6man document as simple as possible, with the details coming
> along later in spring-srv6-network-programming.)
>
>     Brian
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>