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

[Kentaro Ebisawa <[e-mail]>]

Hi Darren,

Apology for the very late reply. I somehow missed this email.
Yes, I have confirmed this is closed based on rev12. (and the recent rev13)

Regards,

On Tue, Apr 24, 2018 at 5:54 AM, Darren Dukes (ddukes) <[e-mail]>
wrote:

> Hi Kentaro, thanks for your comments on rev11 of the draft. I updated the
> definition and description in section 3.2.  I believe that closes this
> issue being tracked:
> #65 <https://trac.ietf.org/trac/6man/ticket/65>
>
> Please verify that this is closed with revision12.
>
> Thanks.
>   Darren
>
> On Apr 6, 2018, at 2:51 AM, Kentaro Ebisawa <[e-mail]> wrote:
>
> Hi,
>
> I have a question about the definition of SL which Ron has pointed out,
> but from a slightly different standpoint.
>
> Recently there was a new function "T.Encaps.Red" defined
> in draft-filsfils-spring-srv6-network-programming-04 which will insert
> SRH with two segments and SL=2.
> > 5.5. T.Encaps.Red: Transit with reduce encaps in an SRv6 Policy
> > 1. push an IPv6 header with its own SRH (S3, S2; SL=2)
>
> And in draft-ietf-6man-segment-routing-header-11 it's defined as follows.
> > "Defined in [RFC8200], it contains the index, in the Segment List, of
> the next segment to inspect.  Segments Left is decremented at each segment."
>
> But since there are only two segments, SegmentList[0] and [1], in the SRH, there
> is no such segment with "INDEX=2".
>
> So the definition in RFC8200 seems more clear which defines SL not as an
> index but as "Number of route segments remaining".
>
> Regards,
> --
> Kentaro Ebisawa <[e-mail]>
>
>
>


-- 
Kentaro Ebisawa <[e-mail]> <[e-mail]>