Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Chris Bowers]

 All,

I'm forwarding this question and subsequent response to the list because it
looks like I accidentally sent it only to Peter before.

Chris

On Sat, Feb 8, 2020 at 3:25 AM Peter Psenak  wrote:

> Hi Chris,
>
> On 07/02/2020 23:15, Chris Bowers wrote:
> > Peter,
> >
> > Thanks for the clarification.
> >
> > Can you also clarify how a receiver should interpret a locator
> > advertisement that doesn't have a corresponding RFC7794 advertisement?
> >
> > Modifying the example below,  suppose I receive a locator advertisement
> > from router R7 with locator = ::/64 and End-SID ::1, but R7
> > doesn't originate an RFC7794 advertisement for ::/64.  Can I
> > conclude that ::/64 is not Anycast, so it can be used as a Node-SID
> > when constructing TE paths as discussed below ?
>
> yes. That's the only reasonable choice.
>
> Implementation may also check if the same locator is not advertised by
> some other node in addition. But I would not mandate that in the spec.
>
> thanks,
> Peter
> >
> > Thanks,
> > Chris
> >
> > On Wed, Feb 5, 2020 at 5:28 AM Peter Psenak  > > wrote:
> >
> > Hi Chris,
> >
> > On 04/02/2020 23:17, Chris Bowers wrote:
> >  > Peter,
> >  >
> >  > Suppose I receive a locator advertisement from router R7 with
> >  > locator = ::/64 and End-SID ::1.  I would like to be able
> > to use
> >  > End-SID ::1 as
> >  > a Node-SID when constructing traffic engineered paths.  That is,
> > I want
> >  > to know that
> >  > the person or system that configured R7 believes that ::/64
> >  > is NOT owned by more than one router within the same routing
> domain.
> >
> > ##PP
> > sure, if the A-bit is not set, you should be fine to pick the SID
> > from a
> > locator. Please see below why.
> >
> >  >
> >  > Since we are going with Interpretation I) below, a prefix can be
> > (a) a
> >  > Node Prefix, (b) an Anycast Prefix,
> >  > or (c) neither of them.
> >
> > ##PP
> > above is correct in general.
> >
> > However, given that locator is non-/128, N-bit does not apply per
> > RFC7794. So for a locator you only have (b) or (c) and you would only
> > want to avoid (b) for what you want to do above.
> >
> >
> >  > If I receive an RFC7794 advertisement from R7
> >  > for ::/64 with N=0, A=0,
> >  > I can only conclude that ::/64 is either (a) a Node Prefix or
> > (c)
> >  > neither a Node Prefix nor an
> >  > Anycast Prefix. Using the N-flag for a non-/128 would allow us to
> >  > unambiguously indicate that
> >  > ::/64 is a Node Prefix, so we can use the associated End-SID
> > ::1
> >  > in a manner
> >  > consistent with the knowledge that ::/64 is NOT owned by more
> > than
> >  > one router
> >  > within the same routing domain.
> >  >
> >  > One other small point relates to the statement below that
> > "locators are
> >  > never /128".
> >  > I don't think it would be very useful to configure a /128
> > locator, since
> >  > it only has
> >  > space for one SRv6 SID.   However, the current text of
> >  > draft-ietf-lsr-isis-srv6-extensions explicitly
> >  > allows the Loc-Size to be 1-128.
> >
> > ##PP
> > agree, but I don't believe we need to put any special text to state
> the
> > above, it's obvious.
> >
> > thanks,
> > Peter
> >  >
> >  > Thanks,
> >  > Chris
> >  >
> >  > On Tue, Feb 4, 2020 at 2:44 AM Peter Psenak  > 
> >  > >> wrote:
> >  >
> >  > Hi Chris,
> >  >
> >  > On 03/02/2020 14:39, Peter Psenak wrote:
> >  >  >> I think a reasonable solution would be to remove the
> > restriction
> >  >  >>
> >  >  >> on the N-flag to allow it to be used for non-/128
> >  > prefixes/locators.  This
> >  >  >>
> >  >  >> would allow the three possible prefix-SIDs states to be
> > easily
> >  > represented.
> >  >  > ##PP
> >  >  > right, that could be a possibility, which would allow SRv6
> > locator to
> >  >  > have the "node" property, as locators are never /128.
> >  >
> >  > do you have a use case, where the locator would need a N-flag?
> >  >
> >  > I can not really think of any, so unless we have one, we
> > better not
> >  > define an N-flag for a non-/128 locator prefix.
> >  >
> >  > thanks,
> >  > Peter
> >  >
> >  > On Mon, Feb 3, 2020 at 7:39 AM Peter Psenak  > 
> >  > >> wrote:
> >  >
> >  > Hi Chris,
> >  >
> >  > adding to what Les has said.
> >  > Please see inline (##PP)
> >  >
> >  >

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Chris Bowers]

All,

I'm forwarding this question and subsequent response to the list because it
looks like I accidentally sent it only to Peter before.

Chris

On Fri, Feb 7, 2020 at 4:15 PM Chris Bowers 
wrote:

> Peter,
>
> Thanks for the clarification.
>
> Can you also clarify how a receiver should interpret a locator
> advertisement that doesn't have a corresponding RFC7794 advertisement?
>
> Modifying the example below,  suppose I receive a locator advertisement
> from router R7 with locator = ::/64 and End-SID ::1, but R7 doesn't
> originate an RFC7794 advertisement for ::/64.  Can I conclude that
> ::/64 is not Anycast, so it can be used as a Node-SID when constructing
> TE paths as discussed below ?
>
> Thanks,
> Chris
>
> On Wed, Feb 5, 2020 at 5:28 AM Peter Psenak  wrote:
>
>> Hi Chris,
>>
>> On 04/02/2020 23:17, Chris Bowers wrote:
>> > Peter,
>> >
>> > Suppose I receive a locator advertisement from router R7 with
>> > locator = ::/64 and End-SID ::1.  I would like to be able to
>> use
>> > End-SID ::1 as
>> > a Node-SID when constructing traffic engineered paths.  That is, I want
>> > to know that
>> > the person or system that configured R7 believes that ::/64
>> > is NOT owned by more than one router within the same routing domain.
>>
>> ##PP
>> sure, if the A-bit is not set, you should be fine to pick the SID from a
>> locator. Please see below why.
>>
>> >
>> > Since we are going with Interpretation I) below, a prefix can be (a) a
>> > Node Prefix, (b) an Anycast Prefix,
>> > or (c) neither of them.
>>
>> ##PP
>> above is correct in general.
>>
>> However, given that locator is non-/128, N-bit does not apply per
>> RFC7794. So for a locator you only have (b) or (c) and you would only
>> want to avoid (b) for what you want to do above.
>>
>>
>> > If I receive an RFC7794 advertisement from R7
>> > for ::/64 with N=0, A=0,
>> > I can only conclude that ::/64 is either (a) a Node Prefix or (c)
>> > neither a Node Prefix nor an
>> > Anycast Prefix. Using the N-flag for a non-/128 would allow us to
>> > unambiguously indicate that
>> > ::/64 is a Node Prefix, so we can use the associated End-SID
>> ::1
>> > in a manner
>> > consistent with the knowledge that ::/64 is NOT owned by more than
>> > one router
>> > within the same routing domain.
>> >
>> > One other small point relates to the statement below that "locators are
>> > never /128".
>> > I don't think it would be very useful to configure a /128 locator,
>> since
>> > it only has
>> > space for one SRv6 SID.   However, the current text of
>> > draft-ietf-lsr-isis-srv6-extensions explicitly
>> > allows the Loc-Size to be 1-128.
>>
>> ##PP
>> agree, but I don't believe we need to put any special text to state the
>> above, it's obvious.
>>
>> thanks,
>> Peter
>> >
>> > Thanks,
>> > Chris
>> >
>> > On Tue, Feb 4, 2020 at 2:44 AM Peter Psenak > > > wrote:
>> >
>> > Hi Chris,
>> >
>> > On 03/02/2020 14:39, Peter Psenak wrote:
>> >  >> I think a reasonable solution would be to remove the restriction
>> >  >>
>> >  >> on the N-flag to allow it to be used for non-/128
>> > prefixes/locators.  This
>> >  >>
>> >  >> would allow the three possible prefix-SIDs states to be easily
>> > represented.
>> >  > ##PP
>> >  > right, that could be a possibility, which would allow SRv6
>> locator to
>> >  > have the "node" property, as locators are never /128.
>> >
>> > do you have a use case, where the locator would need a N-flag?
>> >
>> > I can not really think of any, so unless we have one, we better not
>> > define an N-flag for a non-/128 locator prefix.
>> >
>> > thanks,
>> > Peter
>> >
>> > On Mon, Feb 3, 2020 at 7:39 AM Peter Psenak > > > wrote:
>> >
>> > Hi Chris,
>> >
>> > adding to what Les has said.
>> > Please see inline (##PP)
>> >
>> > On 31/01/2020 21:10, Chris Bowers wrote:
>> >  > Peter and Les,
>> >  >
>> >  > It seems to me that for the Node Flag in RFC7794 and the proposed
>> >  > Anycast Flag
>> >  >
>> >  > in draft-ietf-lsr-isis-srv6-extensions-04, we are ultimately
>> > concerned with
>> >  >
>> >  > how to identify IGP-Node Segments and IGP-Anycast Segments, as
>> > defined
>> >  > in RFC8402,
>> >  >
>> >  > the Segment Routing Architecture document.
>> >  >
>> >  > If this is the case, then the following text from RFC8402 is very
>> > relevant.
>> >  >
>> >  > 
>> >  >
>> >  > 3.2.  IGP-Node Segment (Node-SID)
>> >  >
>> >  > An IGP Node-SID MUST NOT be associated with a prefix that is
>> > owned by
>> >  >
>> >  > more than one router within the same routing domain..
>> >  >
>> >  > 3.3.  IGP-Anycast Segment (Anycast-SID)
>> >  >
>> >  > 
>> >  >
>> >  > An IGP-Anycast segment MUST NOT reference a 

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Ahmed Bashandy]

As a co-author I support this draft and I am not aware of any 
undisclosed IPR related to this draft


Ahmed


On 1/21/20 4:14 PM, Christian Hopps wrote:

This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
draft-ietf-lsr-isis-srv6-extensions

   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

Authors please indicate if you aware of any other IPR beyond what is posted:

   https://datatracker.ietf.org/ipr/3796/

Thanks,
Chris & Acee.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Peter Psenak]

Hi Chris,

On 04/02/2020 23:17, Chris Bowers wrote:

Peter,

Suppose I receive a locator advertisement from router R7 with
locator = ::/64 and End-SID ::1.  I would like to be able to use 
End-SID ::1 as
a Node-SID when constructing traffic engineered paths.  That is, I want 
to know that

the person or system that configured R7 believes that ::/64
is NOT owned by more than one router within the same routing domain.


##PP
sure, if the A-bit is not set, you should be fine to pick the SID from a 
locator. Please see below why.




Since we are going with Interpretation I) below, a prefix can be (a) a 
Node Prefix, (b) an Anycast Prefix,
or (c) neither of them.  


##PP
above is correct in general.

However, given that locator is non-/128, N-bit does not apply per 
RFC7794. So for a locator you only have (b) or (c) and you would only 
want to avoid (b) for what you want to do above.



If I receive an RFC7794 advertisement from R7 
for ::/64 with N=0, A=0,
I can only conclude that ::/64 is either (a) a Node Prefix or (c) 
neither a Node Prefix nor an
Anycast Prefix. Using the N-flag for a non-/128 would allow us to  
unambiguously indicate that
::/64 is a Node Prefix, so we can use the associated End-SID ::1 
in a manner
consistent with the knowledge that ::/64 is NOT owned by more than 
one router

within the same routing domain.

One other small point relates to the statement below that "locators are 
never /128".
I don't think it would be very useful to configure a /128 locator, since 
it only has
space for one SRv6 SID.   However, the current text of 
draft-ietf-lsr-isis-srv6-extensions explicitly

allows the Loc-Size to be 1-128.


##PP
agree, but I don't believe we need to put any special text to state the 
above, it's obvious.


thanks,
Peter


Thanks,
Chris

On Tue, Feb 4, 2020 at 2:44 AM Peter Psenak > wrote:


Hi Chris,

On 03/02/2020 14:39, Peter Psenak wrote:
 >> I think a reasonable solution would be to remove the restriction
 >>
 >> on the N-flag to allow it to be used for non-/128
prefixes/locators.  This
 >>
 >> would allow the three possible prefix-SIDs states to be easily
represented.
 > ##PP
 > right, that could be a possibility, which would allow SRv6 locator to
 > have the "node" property, as locators are never /128.

do you have a use case, where the locator would need a N-flag?

I can not really think of any, so unless we have one, we better not
define an N-flag for a non-/128 locator prefix.

thanks,
Peter

On Mon, Feb 3, 2020 at 7:39 AM Peter Psenak > wrote:


Hi Chris,

adding to what Les has said.
Please see inline (##PP)

On 31/01/2020 21:10, Chris Bowers wrote:
 > Peter and Les,
 >
 > It seems to me that for the Node Flag in RFC7794 and the proposed
 > Anycast Flag
 >
 > in draft-ietf-lsr-isis-srv6-extensions-04, we are ultimately
concerned with
 >
 > how to identify IGP-Node Segments and IGP-Anycast Segments, as
defined
 > in RFC8402,
 >
 > the Segment Routing Architecture document.
 >
 > If this is the case, then the following text from RFC8402 is very
relevant.
 >
 > 
 >
 > 3.2.  IGP-Node Segment (Node-SID)
 >
 >     An IGP Node-SID MUST NOT be associated with a prefix that is
owned by
 >
 >     more than one router within the same routing domain..
 >
 > 3.3.  IGP-Anycast Segment (Anycast-SID)
 >
 >     
 >
 >     An IGP-Anycast segment MUST NOT reference a particular node.
 >
 >     .
 >
 > 
 >
 > This text can be interpreted in two different ways.
 >
 > Interpretation I)
 >
 > A prefix-SID can have the following three possible states.
 >
 > Ia) Node-SID
 >
 > Ib) Anycast-SID
 >
 > Ic) neither Node-SID nor Anycast-SID

##PP
Prefix can either be Node Prefix, Anycast Prefix or neither of them.


 >
 > Interpretation II)
 >
 > A prefix-SID can have the following two possible states.
 >
 > IIa) Node-SID
 >
 > IIb) Anycast-SID
 >
 > If Interpretation I) is correct, then I think that the current
encodings in
 >
 > draft-ietf-lsr-isis-srv6-extensions-04 do not allow us
 >
 > to unambiguously identify a Node-SID for a non-/128
 >
 > prefix/locator.  For example, the End-SIDs within a /64 locator
with the
 > A-flag set could
 >
 > either be Ia) a Node-SID

##PP
rfc7794 does not allow the N-flag to be set for non-/128 prefix, so
above is not possible for /64 locator at the moment.

If the A-flag is set, it is an anycast locator.



 >or Ic) neither Node-SID nor Anycast-SID.

##PP
if the A-flag was not set for /64 locator, above would be correct, but
given that the A-flag is 

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Chris Bowers]

 Peter,

Suppose I receive a locator advertisement from router R7 with
locator = ::/64 and End-SID ::1.  I would like to be able to use
End-SID ::1 as
a Node-SID when constructing traffic engineered paths.  That is, I want to
know that
the person or system that configured R7 believes that ::/64
is NOT owned by more than one router within the same routing domain.

Since we are going with Interpretation I) below, a prefix can be (a) a Node
Prefix, (b) an Anycast Prefix,
or (c) neither of them.  If I receive an RFC7794 advertisement from R7 for
::/64 with N=0, A=0,
I can only conclude that ::/64 is either (a) a Node Prefix or (c)
neither a Node Prefix nor an
Anycast Prefix. Using the N-flag for a non-/128 would allow us to
unambiguously indicate that
::/64 is a Node Prefix, so we can use the associated End-SID ::1 in
a manner
consistent with the knowledge that ::/64 is NOT owned by more than one
router
within the same routing domain.

One other small point relates to the statement below that "locators are
never /128".
I don't think it would be very useful to configure a /128 locator, since it
only has
space for one SRv6 SID.   However, the current text of
draft-ietf-lsr-isis-srv6-extensions explicitly
allows the Loc-Size to be 1-128.

Thanks,
Chris

On Tue, Feb 4, 2020 at 2:44 AM Peter Psenak  wrote:

> Hi Chris,
>
> On 03/02/2020 14:39, Peter Psenak wrote:
> >> I think a reasonable solution would be to remove the restriction
> >>
> >> on the N-flag to allow it to be used for non-/128 prefixes/locators.
> This
> >>
> >> would allow the three possible prefix-SIDs states to be easily
> represented.
> > ##PP
> > right, that could be a possibility, which would allow SRv6 locator to
> > have the "node" property, as locators are never /128.
>
> do you have a use case, where the locator would need a N-flag?
>
> I can not really think of any, so unless we have one, we better not
> define an N-flag for a non-/128 locator prefix.
>
> thanks,
> Peter
>
On Mon, Feb 3, 2020 at 7:39 AM Peter Psenak  wrote:

> Hi Chris,
>
> adding to what Les has said.
> Please see inline (##PP)
>
> On 31/01/2020 21:10, Chris Bowers wrote:
> > Peter and Les,
> >
> > It seems to me that for the Node Flag in RFC7794 and the proposed
> > Anycast Flag
> >
> > in draft-ietf-lsr-isis-srv6-extensions-04, we are ultimately concerned
> with
> >
> > how to identify IGP-Node Segments and IGP-Anycast Segments, as defined
> > in RFC8402,
> >
> > the Segment Routing Architecture document.
> >
> > If this is the case, then the following text from RFC8402 is very
> relevant.
> >
> > 
> >
> > 3.2.  IGP-Node Segment (Node-SID)
> >
> > An IGP Node-SID MUST NOT be associated with a prefix that is owned by
> >
> > more than one router within the same routing domain.
> >
> > 3.3.  IGP-Anycast Segment (Anycast-SID)
> >
> > 
> >
> > An IGP-Anycast segment MUST NOT reference a particular node.
> >
> > .
> >
> > 
> >
> > This text can be interpreted in two different ways.
> >
> > Interpretation I)
> >
> > A prefix-SID can have the following three possible states.
> >
> > Ia) Node-SID
> >
> > Ib) Anycast-SID
> >
> > Ic) neither Node-SID nor Anycast-SID
>
> ##PP
> Prefix can either be Node Prefix, Anycast Prefix or neither of them.
>
>
> >
> > Interpretation II)
> >
> > A prefix-SID can have the following two possible states.
> >
> > IIa) Node-SID
> >
> > IIb) Anycast-SID
> >
> > If Interpretation I) is correct, then I think that the current encodings
> in
> >
> > draft-ietf-lsr-isis-srv6-extensions-04 do not allow us
> >
> > to unambiguously identify a Node-SID for a non-/128
> >
> > prefix/locator.  For example, the End-SIDs within a /64 locator with the
> > A-flag set could
> >
> > either be Ia) a Node-SID
>
> ##PP
> rfc7794 does not allow the N-flag to be set for non-/128 prefix, so
> above is not possible for /64 locator at the moment.
>
> If the A-flag is set, it is an anycast locator.
>
>
>
> >or Ic) neither Node-SID nor Anycast-SID.
>
> ##PP
> if the A-flag was not set for /64 locator, above would be correct, but
> given that the A-flag is set, it is clearly just Anycast locator.
>
> >
> > I think a reasonable solution would be to remove the restriction
> >
> > on the N-flag to allow it to be used for non-/128 prefixes/locators.
> This
> >
> > would allow the three possible prefix-SIDs states to be easily
> represented.
>
> ##PP
> right, that could be a possibility, which would allow SRv6 locator to
> have the "node" property, as locators are never /128.
>
> thanks,
> Peter
>
>
> >
> > If Interpretation II) is correct, then I think that the current
> > encodings in
> >
> > draft-ietf-lsr-isis-srv6-extensions-04 need clarification with respect to
> >
> > how to interpret a /128 prefix/locator advertisement with N=0, A=0. We
> >
> > have to decide between interpreting the End-SIDs within the locator
> >
> > as either Node-SIDs or Anycast-SIDs, since there is no third option.

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Peter Psenak]

Hi Chris,

On 03/02/2020 14:39, Peter Psenak wrote:

I think a reasonable solution would be to remove the restriction

on the N-flag to allow it to be used for non-/128 prefixes/locators.  This

would allow the three possible prefix-SIDs states to be easily represented.

##PP
right, that could be a possibility, which would allow SRv6 locator to
have the "node" property, as locators are never /128.


do you have a use case, where the locator would need a N-flag?

I can not really think of any, so unless we have one, we better not 
define an N-flag for a non-/128 locator prefix.


thanks,
Peter



thanks,
Peter




___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Dongjie (Jimmy)]

I support progressing this draft.

Best regards,
Jie

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> Sent: Wednesday, January 22, 2020 8:15 AM
> To: lsr@ietf.org
> Cc: lsr-...@ietf.org; Christian Hopps ; Acee Lindem
> (acee) 
> Subject: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
> 
> This begins a 2 week WG Last Call, ending after Feb 4, 2020, for
> draft-ietf-lsr-isis-srv6-extensions
> 
>   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/
> 
> Authors please indicate if you aware of any other IPR beyond what is posted:
> 
>   https://datatracker.ietf.org/ipr/3796/
> 
> Thanks,
> Chris & Acee.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Peter Psenak]

Hi Chris,

adding to what Les has said.
Please see inline (##PP)

On 31/01/2020 21:10, Chris Bowers wrote:

Peter and Les,

It seems to me that for the Node Flag in RFC7794 and the proposed 
Anycast Flag


in draft-ietf-lsr-isis-srv6-extensions-04, we are ultimately concerned with

how to identify IGP-Node Segments and IGP-Anycast Segments, as defined 
in RFC8402,


the Segment Routing Architecture document.

If this is the case, then the following text from RFC8402 is very relevant.



3.2.  IGP-Node Segment (Node-SID)

    An IGP Node-SID MUST NOT be associated with a prefix that is owned by

    more than one router within the same routing domain.

3.3.  IGP-Anycast Segment (Anycast-SID)

    

    An IGP-Anycast segment MUST NOT reference a particular node.

    .



This text can be interpreted in two different ways.

Interpretation I)

A prefix-SID can have the following three possible states.

Ia) Node-SID

Ib) Anycast-SID

Ic) neither Node-SID nor Anycast-SID


##PP
Prefix can either be Node Prefix, Anycast Prefix or neither of them.




Interpretation II)

A prefix-SID can have the following two possible states.

IIa) Node-SID

IIb) Anycast-SID

If Interpretation I) is correct, then I think that the current encodings in

draft-ietf-lsr-isis-srv6-extensions-04 do not allow us

to unambiguously identify a Node-SID for a non-/128

prefix/locator.  For example, the End-SIDs within a /64 locator with the 
A-flag set could


either be Ia) a Node-SID


##PP
rfc7794 does not allow the N-flag to be set for non-/128 prefix, so 
above is not possible for /64 locator at the moment.


If the A-flag is set, it is an anycast locator.




or Ic) neither Node-SID nor Anycast-SID.


##PP
if the A-flag was not set for /64 locator, above would be correct, but 
given that the A-flag is set, it is clearly just Anycast locator.




I think a reasonable solution would be to remove the restriction

on the N-flag to allow it to be used for non-/128 prefixes/locators.  This

would allow the three possible prefix-SIDs states to be easily represented.


##PP
right, that could be a possibility, which would allow SRv6 locator to 
have the "node" property, as locators are never /128.


thanks,
Peter




If Interpretation II) is correct, then I think that the current 
encodings in


draft-ietf-lsr-isis-srv6-extensions-04 need clarification with respect to

how to interpret a /128 prefix/locator advertisement with N=0, A=0. We

have to decide between interpreting the End-SIDs within the locator

as either Node-SIDs or Anycast-SIDs, since there is no third option.

I think that interpreting the End-SIDs as Anycast-SIDs in the N=0, A=0

case is preferable because it preserves backwards compatibility.


Thanks,

Chris



On Thu, Jan 30, 2020 at 4:02 AM Peter Psenak > wrote:


Hi Chris,

please see inline (##PP)

On 29/01/2020 17:25, Chris Bowers wrote:
 > I would like to proposed the following text to make section 6
more clear.
 >
 > Thanks,
 > Chris
 >
 > 
 >
 >   (existing text)
 >
 >
 > 6.  Advertising Anycast Property
 >
 >     Both prefixes and SRv6 Locators may be configured as anycast
and as
 >
 >     such the same value can be advertised by multiple routers.  It is
 >
 >     useful for other routers to know that the advertisement is for an
 >
 >     anycast identifier.
 >
 >     A new flag in "Bit Values for Prefix Attribute Flags Sub-TLV"
 >
 >     registry [RFC7794] is defined to advertise the anycast property:
 >
 >     Bit #: 4 (Suggested - to be assigned by IANA)
 >
 >     Name: Anycast Flag (A-flag)
 >
 >     When the prefix/SRv6 locator is configured as anycast,
the A-flag
 >
 >     SHOULD be set. Otherwise, this flag MUST be clear.
 >
 >     The A-flag MUST be preserved when leaked between levels.
 >
 >     The A-flag and the N-flag MUST NOT both be set.
 >
 >  start insert new text ===
 >
 >
 > Certain use cases require prefixes/locators that uniquely belong
to a node.
 >
 > Since prefixes/locators which are not /128 should not have the N
bit set,
 >
 > this node local uniqueness is decided based on A bit for non-/128
prefixes.

##PP
above does not seem correct. Above seems to imply that for non-/128
prefix, A-bit is replacement of N-bit.

A-bit applies to both /128 and non-/128 prefixes equally.

Current draft clearly states what to do when both N a A bits are set.



 >
 >     When a prefix/locator iscategorized as anycast, it does not
uniquely
 > belong
 >
 >     to a node and cannot be used for such use cases.  The rules
below
 > specify
 >
 >     how to determine whether or not a prefix/locator should be
treated
 > as anycast
  

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Ahmed Bashandy]

I am not aware of any IPR that has not been disclosed


Ahmed


On 1/21/20 4:14 PM, Christian Hopps wrote:

This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
draft-ietf-lsr-isis-srv6-extensions

   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

Authors please indicate if you aware of any other IPR beyond what is posted:

   https://datatracker.ietf.org/ipr/3796/

Thanks,
Chris & Acee.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Les Ginsberg (ginsberg)]

Chris –

One of the early mistakes that was made when defining SR-MPLS was defining the 
N-flag (and R-flag) in the Prefix-SID sub-TLV.
We quickly realized that these flags had meaning and use cases for the prefix – 
not simply for the SID.

RFC 7794 was then written and these flags were associated with a prefix (NOT a 
SID) – both for IPv4 and IPv6.

We also added in https://www.rfc-editor.org/rfc/rfc8667.html#section-2.1.1

“The Prefix Attribute Flags sub-TLV 
[RFC7794<https://www.rfc-editor.org/rfc/rfc8667.html#RFC7794>] also defines the 
N-Flag and R-Flag and with the same semantics of the equivalent flags defined 
in this document. Whenever the Prefix Attribute Flags sub-TLV is present for a 
given prefix, the values of the N-Flag and R-Flag advertised in that sub-TLV 
MUST be used, and the values in a corresponding Prefix-SID sub-TLV (if present) 
MUST be ignored.”

to address backwards compatibility with early SR-MPLS IS-IS implementations.
In a perfect world the N/R flags would not exist in the Prefix-SID 
advertisement.

We do not want to make the same mistake again.

The A-flag is a property of a prefix – and (as per 
draft-ietf-lsr-isis-srv6-extensions) also a Locator.

It is a mistake to think that these flags are associated with a SID.

Does this help?

   Les


From: Lsr  On Behalf Of Chris Bowers
Sent: Friday, January 31, 2020 12:11 PM
To: Peter Psenak (ppsenak) ; Les Ginsberg (ginsberg) 

Cc: lsr@ietf.org; lsr-...@ietf.org; Christian Hopps ; Acee 
Lindem (acee) 
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Peter and Les,


It seems to me that for the Node Flag in RFC7794 and the proposed Anycast Flag

in draft-ietf-lsr-isis-srv6-extensions-04, we are ultimately concerned with

how to identify IGP-Node Segments and IGP-Anycast Segments, as defined in 
RFC8402,

the Segment Routing Architecture document.



If this is the case, then the following text from RFC8402 is very relevant.



3.2.  IGP-Node Segment (Node-SID)



   An IGP Node-SID MUST NOT be associated with a prefix that is owned by

   more than one router within the same routing domain.



3.3.  IGP-Anycast Segment (Anycast-SID)

   

   An IGP-Anycast segment MUST NOT reference a particular node.
   .

This text can be interpreted in two different ways.

Interpretation I)
A prefix-SID can have the following three possible states.
Ia) Node-SID
Ib) Anycast-SID
Ic) neither Node-SID nor Anycast-SID

Interpretation II)
A prefix-SID can have the following two possible states.
IIa) Node-SID
IIb) Anycast-SID

If Interpretation I) is correct, then I think that the current encodings in
draft-ietf-lsr-isis-srv6-extensions-04 do not allow us
to unambiguously identify a Node-SID for a non-/128
prefix/locator.  For example, the End-SIDs within a /64 locator with the A-flag 
set could
either be Ia) a Node-SID  or Ic) neither Node-SID nor Anycast-SID.
I think a reasonable solution would be to remove the restriction
on the N-flag to allow it to be used for non-/128 prefixes/locators.  This
would allow the three possible prefix-SIDs states to be easily represented.

If Interpretation II) is correct, then I think that the current encodings in
draft-ietf-lsr-isis-srv6-extensions-04 need clarification with respect to
how to interpret a /128 prefix/locator advertisement with N=0, A=0. We
have to decide between interpreting the End-SIDs within the locator
as either Node-SIDs or Anycast-SIDs, since there is no third option.
I think that interpreting the End-SIDs as Anycast-SIDs in the N=0, A=0
case is preferable because it preserves backwards compatibility.

Thanks,
Chris



On Thu, Jan 30, 2020 at 4:02 AM Peter Psenak 
mailto:ppse...@cisco.com>> wrote:
Hi Chris,

please see inline (##PP)

On 29/01/2020 17:25, Chris Bowers wrote:
> I would like to proposed the following text to make section 6 more clear.
>
> Thanks,
> Chris
>
> 
>
>   (existing text)
>
>
> 6.  Advertising Anycast Property
>
> Both prefixes and SRv6 Locators may be configured as anycast and as
>
> such the same value can be advertised by multiple routers.  It is
>
> useful for other routers to know that the advertisement is for an
>
> anycast identifier.
>
> A new flag in "Bit Values for Prefix Attribute Flags Sub-TLV"
>
> registry [RFC7794] is defined to advertise the anycast property:
>
> Bit #: 4 (Suggested - to be assigned by IANA)
>
> Name: Anycast Flag (A-flag)
>
> When the prefix/SRv6 locator is configured as anycast, the A-flag
>
> SHOULD be set. Otherwise, this flag MUST be clear.
>
> The A-flag MUST be preserved when leaked between levels.
>
> The A-flag and the N-flag MUST NOT both be set.
>
>  start insert new text ===
>
>
> Certain use cases require prefixes/locators that uniquely b

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Chris Bowers]

Peter and Les,

It seems to me that for the Node Flag in RFC7794 and the proposed Anycast Flag

in draft-ietf-lsr-isis-srv6-extensions-04, we are ultimately concerned with

how to identify IGP-Node Segments and IGP-Anycast Segments, as defined
in RFC8402,

the Segment Routing Architecture document.



If this is the case, then the following text from RFC8402 is very relevant.



3.2.  IGP-Node Segment (Node-SID)



   An IGP Node-SID MUST NOT be associated with a prefix that is owned by

   more than one router within the same routing domain.



3.3.  IGP-Anycast Segment (Anycast-SID)

   

   An IGP-Anycast segment MUST NOT reference a particular node.

   



This text can be interpreted in two different ways.



Interpretation I)

A prefix-SID can have the following three possible states.

Ia) Node-SID

Ib) Anycast-SID

Ic) neither Node-SID nor Anycast-SID



Interpretation II)

A prefix-SID can have the following two possible states.

IIa) Node-SID

IIb) Anycast-SID



If Interpretation I) is correct, then I think that the current encodings in

draft-ietf-lsr-isis-srv6-extensions-04 do not allow us

to unambiguously identify a Node-SID for a non-/128

prefix/locator.  For example, the End-SIDs within a /64 locator with the
A-flag set could

either be Ia) a Node-SID  or Ic) neither Node-SID nor Anycast-SID.

I think a reasonable solution would be to remove the restriction

on the N-flag to allow it to be used for non-/128 prefixes/locators.  This

would allow the three possible prefix-SIDs states to be easily represented.



If Interpretation II) is correct, then I think that the current encodings
in

draft-ietf-lsr-isis-srv6-extensions-04 need clarification with respect to

how to interpret a /128 prefix/locator advertisement with N=0, A=0. We

have to decide between interpreting the End-SIDs within the locator

as either Node-SIDs or Anycast-SIDs, since there is no third option.

I think that interpreting the End-SIDs as Anycast-SIDs in the N=0, A=0

case is preferable because it preserves backwards compatibility.


Thanks,

Chris




On Thu, Jan 30, 2020 at 4:02 AM Peter Psenak  wrote:

> Hi Chris,
>
> please see inline (##PP)
>
> On 29/01/2020 17:25, Chris Bowers wrote:
> > I would like to proposed the following text to make section 6 more clear.
> >
> > Thanks,
> > Chris
> >
> > 
> >
> >   (existing text)
> >
> >
> > 6.  Advertising Anycast Property
> >
> > Both prefixes and SRv6 Locators may be configured as anycast and as
> >
> > such the same value can be advertised by multiple routers.  It is
> >
> > useful for other routers to know that the advertisement is for an
> >
> > anycast identifier.
> >
> > A new flag in "Bit Values for Prefix Attribute Flags Sub-TLV"
> >
> > registry [RFC7794] is defined to advertise the anycast property:
> >
> > Bit #: 4 (Suggested - to be assigned by IANA)
> >
> > Name: Anycast Flag (A-flag)
> >
> > When the prefix/SRv6 locator is configured as anycast, the A-flag
> >
> > SHOULD be set. Otherwise, this flag MUST be clear.
> >
> > The A-flag MUST be preserved when leaked between levels.
> >
> > The A-flag and the N-flag MUST NOT both be set.
> >
> >  start insert new text ===
> >
> >
> > Certain use cases require prefixes/locators that uniquely belong to a
> node.
> >
> > Since prefixes/locators which are not /128 should not have the N bit set,
> >
> > this node local uniqueness is decided based on A bit for non-/128
> prefixes.
>
> ##PP
> above does not seem correct. Above seems to imply that for non-/128
> prefix, A-bit is replacement of N-bit.
>
> A-bit applies to both /128 and non-/128 prefixes equally.
>
> Current draft clearly states what to do when both N a A bits are set.
>
>
>
> >
> > When a prefix/locator iscategorized as anycast, it does not uniquely
> > belong
> >
> > to a node and cannot be used for such use cases.  The rules below
> > specify
> >
> > how to determine whether or not a prefix/locator should be treated
> > as anycast
> >
> > in various situations.
> >
> >
> > [RFC7794] contains the following restriction on the interpretation
> of the N-flag.
> >
> > "If the flag is set and the prefix length is NOT a host prefix
> >
> >  (/32 for IPV4, /128 forIPv6), then the flag MUST be ignored."
> >
> > The current document does NOT modify this restriction on the
> interpretation of
> >
> > the N-flag imposed by [RFC7794].
>
> ##PP
> I don't think above text is needed. And I don't think above is
> completely correct, as we define a new case in which the N-bit should be
> ignored (when A-bit is set).
>
>
> >
> > For a prefix/SRv6 Locator advertisement with a /128 prefix/locator,
> >
> > if both N-flag and A-flag are set, the receiving router MUST treat
> the
> >
> > prefix advertisement as anycast.
>
> ##PP
> we have following text in the draft already:
>
> "If both N-flag and A-flag 

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Peter Psenak]

Hi Chris,

please see inline (##PP)

On 29/01/2020 17:25, Chris Bowers wrote:

I would like to proposed the following text to make section 6 more clear.

Thanks,
Chris



  (existing text)


6.  Advertising Anycast Property

    Both prefixes and SRv6 Locators may be configured as anycast and as

    such the same value can be advertised by multiple routers.  It is

    useful for other routers to know that the advertisement is for an

    anycast identifier.

    A new flag in "Bit Values for Prefix Attribute Flags Sub-TLV"

    registry [RFC7794] is defined to advertise the anycast property:

    Bit #: 4 (Suggested - to be assigned by IANA)

    Name: Anycast Flag (A-flag)

    When the prefix/SRv6 locator is configured as anycast, the A-flag

    SHOULD be set. Otherwise, this flag MUST be clear.

    The A-flag MUST be preserved when leaked between levels.

    The A-flag and the N-flag MUST NOT both be set.

 start insert new text ===


Certain use cases require prefixes/locators that uniquely belong to a node.

Since prefixes/locators which are not /128 should not have the N bit set,

this node local uniqueness is decided based on A bit for non-/128 prefixes.


##PP
above does not seem correct. Above seems to imply that for non-/128 
prefix, A-bit is replacement of N-bit.


A-bit applies to both /128 and non-/128 prefixes equally.

Current draft clearly states what to do when both N a A bits are set.





    When a prefix/locator iscategorized as anycast, it does not uniquely 
belong


    to a node and cannot be used for such use cases.  The rules below 
specify


    how to determine whether or not a prefix/locator should be treated 
as anycast


    in various situations.


    [RFC7794] contains the following restriction on the interpretation of the 
N-flag.

    "If the flag is set and the prefix length is NOT a host prefix

 (/32 for IPV4, /128 forIPv6), then the flag MUST be ignored."

    The current document does NOT modify this restriction on the interpretation 
of

    the N-flag imposed by [RFC7794].


##PP
I don't think above text is needed. And I don't think above is 
completely correct, as we define a new case in which the N-bit should be 
ignored (when A-bit is set).





    For a prefix/SRv6 Locator advertisement with a /128 prefix/locator,

    if both N-flag and A-flag are set, the receiving router MUST treat the

    prefix advertisement as anycast.


##PP
we have following text in the draft already:

"If both N-flag and A-flag are set in the prefix/SRv6 Locator
   advertisement, the receiving routers MUST ignore the N-flag."





    For a prefix/SRv6 Locator advertisement with a /128 prefix/locator,

    if the N-flag and A-flag are NOT set, the receiving routers

    MUST treat the prefix advertisement as anycast.  


##PP
I don't think above statement is correct. Why a node cannot advertise a 
/128 prefix which is not an anycast one and does not have a N-bit set?





This rule ensures the

    correct interpretation of a prefix advertisement originated by

    a router that is not SRv6 capable and originates a legacy

    Prefix Attribute Flags Sub-TLV based on [RFC7794] alone.

    For a prefix/SRv6 Locator advertisement with a prefix/locator that

    is NOT /128, the N-flag must be ignored, so the setting of the

    A-flag determines the anycast treatment of the prefix advertisement.


##PP
A-flag does that regardless of the length of the prefix.




    The Prefix Attribute Flags Sub-TLV can be carried in the SRv6 
Locator TLV


    as well as the Prefix Reachability TLVs.  When a router originates

    both the Prefix Reachability TLV and the SRv6 Locator TLV for a given

    prefix, and the router is originating the Prefix Attribute Flags Sub-TLV

    in one of the TLVs, the router SHOULD advertise identical versions of the

    Prefix Attribute Flags Sub-TLV in both TLVs.


##PP
Above seems a good suggestion. Will add it.



  


    If a router receives one Prefix Attribute Flags Sub-TLV in the

    Prefix Reachability TLV and another in the SRv6 Locator TLV, the router 
should

    use the prefix attribute flags received in the Prefix Reachability TLV.


##PP
above contradicts what you suggest in the previous paragraph, where you 
suggest we need to advertise with both prefix and locator, and here you 
suggest we ignore what we received in the locator.


Are you talking about the case where the content of the Prefix Attribute 
Flags Sub-TLV is different in prefix vs locator?


  


    If a router receives a Prefix Attribute Flags Sub-TLV in the

    Prefix Reachability TLV but not in the SRv6 Locator TLV, the router should

    use the prefix attribute flags received in the Prefix Reachability TLV.


##PP
do we really need this? If the originator does the right thing, then we 
don't have the problem. Cross referencing data between different TLVs 
complicates the implementations.





  


    If a router receives 

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Les Ginsberg (ginsberg)]

Chris –

I will let the authors of isis-srv6-extensions reply to the bulk of your 
suggestion.
But as an author of RFC 7794, I do have some concerns.

Please see inline.

From: Lsr  On Behalf Of Chris Bowers
Sent: Wednesday, January 29, 2020 8:25 AM
To: lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps ; Acee Lindem (acee) 

Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

I would like to proposed the following text to make section 6 more clear.

Thanks,
Chris

 (existing text)

6.  Advertising Anycast Property

   Both prefixes and SRv6 Locators may be configured as anycast and as
   such the same value can be advertised by multiple routers.  It is
   useful for other routers to know that the advertisement is for an
   anycast identifier.

   A new flag in "Bit Values for Prefix Attribute Flags Sub-TLV"
   registry [RFC7794] is defined to advertise the anycast property:

   Bit #: 4 (Suggested - to be assigned by IANA)
   Name: Anycast Flag (A-flag)

   When the prefix/SRv6 locator is configured as anycast, the A-flag
   SHOULD be set. Otherwise, this flag MUST be clear.

   The A-flag MUST be preserved when leaked between levels.

   The A-flag and the N-flag MUST NOT both be set.

 start insert new text ===

   Certain use cases require prefixes/locators that uniquely belong to a node.
   Since prefixes/locators which are not /128 should not have the N bit set,
   this node local uniqueness is decided based on A bit for non-/128 prefixes.
   When a prefix/locator is categorized as anycast, it does not uniquely belong
   to a node and cannot be used for such use cases.  The rules below specify
   how to determine whether or not a prefix/locator should be treated as anycast
   in various situations.


   [RFC7794] contains the following restriction on the interpretation of the 
N-flag.

   "If the flag is set and the prefix length is NOT a host prefix

(/32 for IPV4, /128 for IPv6), then the flag MUST be ignored."



   The current document does NOT modify this restriction on the interpretation 
of

   the N-flag imposed by [RFC7794].

[Les:] I am not sure why you feel the above two paragraphs are necessary. In 
general, I find the idea that I have to say “I am not changing that other 
specification” disturbing.
It suggests that the document should list everything else which it isn’t 
changing.
Perhaps you feel that there is something in the current text which suggests 
that the meaning of the N flag when associated with a non-host prefix has been 
changed by this document? If so, please point out that text.

   For a prefix/SRv6 Locator advertisement with a /128 prefix/locator,
   if both N-flag and A-flag are set, the receiving router MUST treat the
   prefix advertisement as anycast.

   For a prefix/SRv6 Locator advertisement with a /128 prefix/locator,
   if the N-flag and A-flag are NOT set, the receiving routers
   MUST treat the prefix advertisement as anycast.  This rule ensures the
   correct interpretation of a prefix advertisement originated by
   a router that is not SRv6 capable and originates a legacy
   Prefix Attribute Flags Sub-TLV based on [RFC7794] alone.

[Les:] This suggestion confuses me – and seems incorrect.
You imply by this that there are only two possibilities for a host address:
1)It is a node address or
2)It is an anycast address

But it is also possible that the prefix is a unicast address but the originator 
does not intend for the address to be used as a node address.
Your text disallows that possibility.

I get that prior to the definition of the A-bit there is no way to tell by 
looking at a prefix advertisement alone whether the address is anycast (hence 
the desire to define the A-bit).
But it does not then follow that if A-bit and N-bit are both NOT set that this 
is equivalent to having A-bit set.

   Les

   For a prefix/SRv6 Locator advertisement with a prefix/locator that
   is NOT /128, the N-flag must be ignored, so the setting of the
   A-flag determines the anycast treatment of the prefix advertisement.

   The Prefix Attribute Flags Sub-TLV can be carried in the SRv6 Locator TLV
   as well as the Prefix Reachability TLVs.  When a router originates

   both the Prefix Reachability TLV and the SRv6 Locator TLV for a given

   prefix, and the router is originating the Prefix Attribute Flags Sub-TLV

   in one of the TLVs, the router SHOULD advertise identical versions of the

   Prefix Attribute Flags Sub-TLV in both TLVs.



   If a router receives one Prefix Attribute Flags Sub-TLV in the

   Prefix Reachability TLV and another in the SRv6 Locator TLV, the router 
should

   use the prefix attribute flags received in the Prefix Reachability TLV.



   If a router receives a Prefix Attribute Flags Sub-TLV in the

   Prefix Reachability TLV but not in the SRv6 Locator TLV, the router should

   use the prefix attribute flags received in the Prefix Reachability TLV.



   

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Chris Bowers]

I would like to proposed the following text to make section 6 more clear.

Thanks,
Chris



 (existing text)


6.  Advertising Anycast Property



   Both prefixes and SRv6 Locators may be configured as anycast and as

   such the same value can be advertised by multiple routers.  It is

   useful for other routers to know that the advertisement is for an

   anycast identifier.



   A new flag in "Bit Values for Prefix Attribute Flags Sub-TLV"

   registry [RFC7794] is defined to advertise the anycast property:



   Bit #: 4 (Suggested - to be assigned by IANA)

   Name: Anycast Flag (A-flag)



   When the prefix/SRv6 locator is configured as anycast, the A-flag

   SHOULD be set. Otherwise, this flag MUST be clear.



   The A-flag MUST be preserved when leaked between levels.



   The A-flag and the N-flag MUST NOT both be set.



 start insert new text ===


   Certain use cases require prefixes/locators that uniquely belong to a
node.

   Since prefixes/locators which are not /128 should not have the N bit set,

   this node local uniqueness is decided based on A bit for non-/128
prefixes.

   When a prefix/locator is categorized as anycast, it does not uniquely
belong

   to a node and cannot be used for such use cases.  The rules below
specify

   how to determine whether or not a prefix/locator should be treated as
anycast

   in various situations.


   [RFC7794] contains the following restriction on the interpretation
of the N-flag.

   "If the flag is set and the prefix length is NOT a host prefix

(/32 for IPV4, /128 for IPv6), then the flag MUST be ignored."



   The current document does NOT modify this restriction on the
interpretation of

   the N-flag imposed by [RFC7794].



   For a prefix/SRv6 Locator advertisement with a /128 prefix/locator,

   if both N-flag and A-flag are set, the receiving router MUST treat the

   prefix advertisement as anycast.



   For a prefix/SRv6 Locator advertisement with a /128 prefix/locator,

   if the N-flag and A-flag are NOT set, the receiving routers

   MUST treat the prefix advertisement as anycast.  This rule ensures the

   correct interpretation of a prefix advertisement originated by

   a router that is not SRv6 capable and originates a legacy

   Prefix Attribute Flags Sub-TLV based on [RFC7794] alone.



   For a prefix/SRv6 Locator advertisement with a prefix/locator that

   is NOT /128, the N-flag must be ignored, so the setting of the

   A-flag determines the anycast treatment of the prefix advertisement.



   The Prefix Attribute Flags Sub-TLV can be carried in the SRv6 Locator TLV

   as well as the Prefix Reachability TLVs.  When a router originates

   both the Prefix Reachability TLV and the SRv6 Locator TLV for a given

   prefix, and the router is originating the Prefix Attribute Flags Sub-TLV

   in one of the TLVs, the router SHOULD advertise identical versions of the

   Prefix Attribute Flags Sub-TLV in both TLVs.



   If a router receives one Prefix Attribute Flags Sub-TLV in the

   Prefix Reachability TLV and another in the SRv6 Locator TLV, the
router should

   use the prefix attribute flags received in the Prefix Reachability TLV.



   If a router receives a Prefix Attribute Flags Sub-TLV in the

   Prefix Reachability TLV but not in the SRv6 Locator TLV, the router should

   use the prefix attribute flags received in the Prefix Reachability TLV.



   If a router receives a Prefix Attribute Flags Sub-TLV in the

   SRv6 Locator TLV but not in the Prefix Reachability TLV,

   the router should use the prefix attribute flags received in the
SRv6 Locator TLV.



 end insert new text =



   The same prefix/SRv6 Locator can be advertised by multiple routers.

   If at least one of them sets the A-Flag in its advertisement, the

   prefix/SRv6 Locator SHOULD be considered as anycast.



===

On Tue, Jan 21, 2020 at 6:15 PM Christian Hopps  wrote:

> This begins a 2 week WG Last Call, ending after Feb 4, 2020, for
> draft-ietf-lsr-isis-srv6-extensions
>
>   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/
>
> Authors please indicate if you aware of any other IPR beyond what is
> posted:
>
>   https://datatracker.ietf.org/ipr/3796/
>
> Thanks,
> Chris & Acee.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[bruno.decraene]

> From: Peter Psenak [mailto:ppse...@cisco.com] 
> 
> Hi Bruno,
> 
> On 28/01/2020 18:05, bruno.decra...@orange.com wrote:
> > Hi Peter,
> > 
> > Thank you.
> > Looks good.
> > 
> > Just one follow up
> > 
> >>> §9
> >>>
> >>> A priori the sum of all 4 sizes must be 128 bits. Could you specify the
> >>> error handling when this is not the case? (a choice could be to ignore
> >>> this Sub-Sub-TLV; but given the error handling specified for another
> >>> error, you seem to prefer to ignore the whole parent TLV.
> >>
> >> ##PP
> >> the sum may not need to be 128, some fields may be advertised as 0 -
> >> e.g. not all SIDs have arguments.
> > 
> > You are correct.
> > Let me rephrase:
> > 
> > A priori the sum of all 4 sizes must be lower or equal 128 bits.
> > Could you specify the error handling when this is not the case?
> > Especially since there seem to be two possible responses:
> > a) ignore this Sub-Sub-TLV
> > b) ignore the whole parent TLV (as specified for another error condition)
> 
> I would go for (b) and ignore the parent sub-TLV.
> Will update accordingly.

Thank you Peter.

--Bruno

> thanks,
> Peter
> 
> 
> 
> > 
> > Thank you
> > --Bruno
> > 
> >> -----Original Message-
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >> Sent: Monday, January 27, 2020 1:43 PM
> >> To: DECRAENE Bruno TGI/OLN; lsr@ietf.org
> >> Cc: lsr-...@ietf.org; Christian Hopps; Acee Lindem (acee)
> >> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
> >>
> >> Hi Bruno,
> >>
> >> please see inline (##PP):
> >>
> >> On 24/01/2020 16:24, bruno.decra...@orange.com wrote:
> >>> Hi authors, WG,
> >>>
> >>> I've re-read the draft. Please find below some minor comments and nits.
> >>>
> >>> Best regards,
> >>>
> >>> --Bruno
> >>>
> >>> Minors:
> >>>
> >>> ==
> >>>
> >>> " A node indicates that it has support for SRv6 by advertising a new
> >>> SRv6 Capabilities sub-TLV"
> >>>
> >>> I'm not completely certain that "support for SRv6" is perfectly defined.
> >>> Do you have a reference? Otherwise may be "is an SRv6 Segment Endpoint
> >>> Node" would be better.
> >>>
> >>> Cfhttps://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-3
> >>
> >> ##PP
> >> I changed to "SR Segment Endpoint Node"
> >>
> >>
> >>
> >>>
> >>> ---
> >>>
> >>> §4.3
> >>>
> >>> "The Maximum H.Encaps MSD Type specifies the maximum number of SIDsthat
> >>> can be included as part of the "H.Encaps" behavior"
> >>>
> >>> This is not crystal clear to me when the "reduced encapsulation" is
> >>> used. In such case we have:
> >>>
> >>> a) the number of SID included (N)
> >>>
> >>> b) the number of SID included in the SRH (N-1)
> >>>
> >>> Could you clarify which one you are referring to?
> >>>
> >>> I assume that this is "b" given the text:
> >>>
> >>> "If the advertised value is zero then the router can apply H.Encaps only
> >>> by encapsulating the incoming packet in anotherIPv6 header without SRH
> >>> the same way IPinIP encapsulation is performed."
> >>>
> >>> But to avoid interop issue, I'd prefer the spec to be non ambiguous.
> >>> (typically by saying "SIDs in a SRH" as indicated in §4.4
> >>
> >> ##PP
> >> the Maximum H.Encaps MSD Type specifies the maximum number of segments
> >> that a node can use as part of the encapsulation operation, regardless
> >> of whether that is H.Encaps or H.Encaps.Red. If the node advertises N it
> >> can either do H.Encaps with N SIDs in SRH or do H.Encaps.Red with (N-1)
> >> in the SRH +1 in the IPv6 DA.
> >>
> >>
> >>>
> >>> ---
> >>>
> >>> §4.2
> >>>
> >>> "inthe top SRH in an SRH stack to which the router can apply "PSP"
> >>> orUSP" as defined in [I-D.ietf-spring-srv6-network-programming]flavors"
> >>>
> >>> [I-D

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Peter Psenak]

Hi Bruno,

On 28/01/2020 18:05, bruno.decra...@orange.com wrote:

Hi Peter,

Thank you.
Looks good.

Just one follow up


§9

A priori the sum of all 4 sizes must be 128 bits. Could you specify the
error handling when this is not the case? (a choice could be to ignore
this Sub-Sub-TLV; but given the error handling specified for another
error, you seem to prefer to ignore the whole parent TLV.


##PP
the sum may not need to be 128, some fields may be advertised as 0 -
e.g. not all SIDs have arguments.


You are correct.
Let me rephrase:

A priori the sum of all 4 sizes must be lower or equal 128 bits.
Could you specify the error handling when this is not the case?
Especially since there seem to be two possible responses:
a) ignore this Sub-Sub-TLV
b) ignore the whole parent TLV (as specified for another error condition)


I would go for (b) and ignore the parent sub-TLV.
Will update accordingly.

thanks,
Peter





Thank you
--Bruno


-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Monday, January 27, 2020 1:43 PM
To: DECRAENE Bruno TGI/OLN; lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps; Acee Lindem (acee)
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Hi Bruno,

please see inline (##PP):

On 24/01/2020 16:24, bruno.decra...@orange.com wrote:

Hi authors, WG,

I've re-read the draft. Please find below some minor comments and nits.

Best regards,

--Bruno

Minors:

==

" A node indicates that it has support for SRv6 by advertising a new
SRv6 Capabilities sub-TLV"

I'm not completely certain that "support for SRv6" is perfectly defined.
Do you have a reference? Otherwise may be "is an SRv6 Segment Endpoint
Node" would be better.

Cfhttps://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-3


##PP
I changed to "SR Segment Endpoint Node"





---

§4.3

"The Maximum H.Encaps MSD Type specifies the maximum number of SIDsthat
can be included as part of the "H.Encaps" behavior"

This is not crystal clear to me when the "reduced encapsulation" is
used. In such case we have:

a) the number of SID included (N)

b) the number of SID included in the SRH (N-1)

Could you clarify which one you are referring to?

I assume that this is "b" given the text:

"If the advertised value is zero then the router can apply H.Encaps only
by encapsulating the incoming packet in anotherIPv6 header without SRH
the same way IPinIP encapsulation is performed."

But to avoid interop issue, I'd prefer the spec to be non ambiguous.
(typically by saying "SIDs in a SRH" as indicated in §4.4


##PP
the Maximum H.Encaps MSD Type specifies the maximum number of segments
that a node can use as part of the encapsulation operation, regardless
of whether that is H.Encaps or H.Encaps.Red. If the node advertises N it
can either do H.Encaps with N SIDs in SRH or do H.Encaps.Red with (N-1)
in the SRH +1 in the IPv6 DA.




---

§4.2

"inthe top SRH in an SRH stack to which the router can apply "PSP"
orUSP" as defined in [I-D.ietf-spring-srv6-network-programming]flavors"

[I-D.ietf-spring-srv6-network-programming] does not define (anymore)
"SRH stack", nor "top SRH". Please remove those two terms.




##PP
Changed to:

"The Maximum End Pop MSD Type specifies the maximum number of SIDs in
the SRH to which the router can apply "PSP" or USP" behavior, as defined
in [I-D.ietf-spring-srv6-network-programming] flavors."



---

§4.4

"If the advertised value is zero or no value is advertised

then it is assumed that the router cannot apply

"End.DX6" or "End.DT6" behaviors if the extension

header right underneath the outer IPv6 header is an SRH."

There is no requirement for the SRH to be "right underneath the outer
IPv6 header".


##PP
Changed to:

"If the advertised value is zero or no value is advertised
then it is assumed that the router cannot apply
"End.DX6" or "End.DT6" behaviors if the outer IPv6 header contains an SRH."




Cfhttps://tools.ietf.org/html/rfc8200#section-4.1

Please clarify what is meant precisely. E.g.:

a) if there is an SRH

b) if there is a IPv6 routing header

c) if there isan IPv6 extension header

?



Given the wording in §4.2, I would suggest "a". However, the technical
question remains: are those MSD numbers affected by the presence of
another IPv6 extension header (before the SRH)?


##PP
no, the presence of another IPv6 extension header has no impact on the
MSDs we define here.



---

OLD: This is to prevent inconsistent forwarding entries on SRv6
capable/SRv6 incapable routers.

I think the below would be clearer

NEW: This is to prevent inconsistent forwarding entries between SRv6
capable and SRv6 incapable routers.


##PP
fixed as suggested.





§7.1

“

Type: 27 (Suggested value 

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[bruno.decraene]

Hi Peter,

Thank you.
Looks good.

Just one follow up

> > §9
> > 
> > A priori the sum of all 4 sizes must be 128 bits. Could you specify the 
> > error handling when this is not the case? (a choice could be to ignore 
> > this Sub-Sub-TLV; but given the error handling specified for another 
> > error, you seem to prefer to ignore the whole parent TLV.
> 
> ##PP
> the sum may not need to be 128, some fields may be advertised as 0 - 
> e.g. not all SIDs have arguments.

You are correct.
Let me rephrase:

A priori the sum of all 4 sizes must be lower or equal 128 bits.
Could you specify the error handling when this is not the case?
Especially since there seem to be two possible responses:
a) ignore this Sub-Sub-TLV
b) ignore the whole parent TLV (as specified for another error condition)

Thank you
--Bruno

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com] 
> Sent: Monday, January 27, 2020 1:43 PM
> To: DECRAENE Bruno TGI/OLN; lsr@ietf.org
> Cc: lsr-...@ietf.org; Christian Hopps; Acee Lindem (acee)
> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
> 
> Hi Bruno,
> 
> please see inline (##PP):
> 
> On 24/01/2020 16:24, bruno.decra...@orange.com wrote:
> > Hi authors, WG,
> > 
> > I've re-read the draft. Please find below some minor comments and nits.
> > 
> > Best regards,
> > 
> > --Bruno
> > 
> > Minors:
> > 
> > ==
> > 
> > " A node indicates that it has support for SRv6 by advertising a new 
> > SRv6 Capabilities sub-TLV"
> > 
> > I'm not completely certain that "support for SRv6" is perfectly defined. 
> > Do you have a reference? Otherwise may be "is an SRv6 Segment Endpoint 
> > Node" would be better.
> > 
> > Cfhttps://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-3
> 
> ##PP
> I changed to "SR Segment Endpoint Node"
> 
> 
> 
> > 
> > ---
> > 
> > §4.3
> > 
> > "The Maximum H.Encaps MSD Type specifies the maximum number of SIDsthat 
> > can be included as part of the "H.Encaps" behavior"
> > 
> > This is not crystal clear to me when the "reduced encapsulation" is 
> > used. In such case we have:
> > 
> > a) the number of SID included (N)
> > 
> > b) the number of SID included in the SRH (N-1)
> > 
> > Could you clarify which one you are referring to?
> > 
> > I assume that this is "b" given the text:
> > 
> > "If the advertised value is zero then the router can apply H.Encaps only 
> > by encapsulating the incoming packet in anotherIPv6 header without SRH 
> > the same way IPinIP encapsulation is performed."
> > 
> > But to avoid interop issue, I'd prefer the spec to be non ambiguous. 
> > (typically by saying "SIDs in a SRH" as indicated in §4.4
> 
> ##PP
> the Maximum H.Encaps MSD Type specifies the maximum number of segments 
> that a node can use as part of the encapsulation operation, regardless 
> of whether that is H.Encaps or H.Encaps.Red. If the node advertises N it 
> can either do H.Encaps with N SIDs in SRH or do H.Encaps.Red with (N-1) 
> in the SRH +1 in the IPv6 DA.
> 
> 
> > 
> > ---
> > 
> > §4.2
> > 
> > "inthe top SRH in an SRH stack to which the router can apply "PSP" 
> > orUSP" as defined in [I-D.ietf-spring-srv6-network-programming]flavors"
> > 
> > [I-D.ietf-spring-srv6-network-programming] does not define (anymore) 
> > "SRH stack", nor "top SRH". Please remove those two terms.
> 
> > 
> > ##PP
> > Changed to:
> > 
> > "The Maximum End Pop MSD Type specifies the maximum number of SIDs in
> > the SRH to which the router can apply "PSP" or USP" behavior, as defined 
> > in [I-D.ietf-spring-srv6-network-programming] flavors."
> > 
> > > 
> > > ---
> > > 
> > > §4.4
> > > 
> > > "If the advertised value is zero or no value is advertised
> > > 
> > > then it is assumed that the router cannot apply
> > > 
> > > "End.DX6" or "End.DT6" behaviors if the extension
> > > 
> > > header right underneath the outer IPv6 header is an SRH."
> > > 
> > > There is no requirement for the SRH to be "right underneath the outer 
> > > IPv6 header".
> > 
> > ##PP
> > Changed to:
> > 
> > "If the advertised value is zero or no value is advertised
&

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Peter Psenak]

d ‘algorithm’ in the SRv6 End.X 
SID sub-TLV? The 128-bits SID allows identifying the Locator, which 
already advertise an algorithm.


Advertising again the algorithm with the End.X SID waste space and is an 
opportunity for inconsistency hence additional error handling 
rules/implementations.



##PP

Having an algo field advertised with the END.X/LAN END.x SIDs:

1. Makes it easier for implementation to find the algo specific END.X 
SID without making the longest prefix match on all locators advertised 
by the node to find the algo to which the SID belongs.


2. Contrary to what you said, it makes it possible to verify that the 
algorithm associated with the END.X SID matches that of the covering 
Locator.






§8.2

“System-ID: 6 octets of IS-IS System-ID of length "ID Length" as defined 
in [ISO10589  <https://tools.ietf.org/html/draft-ietf-lsr-isis-srv6-extensions-04#ref-ISO10589>]. »


The field seems of fixed length (6 octets) while the encoded System ID 
seems to be of a variable length. If so, wouldn’t it be useful to 
indicate how a System ID of a length shorter than 6 octets is encoded? 
(in most or least significant octets?).


##PP
Les has responded to the above.





§9

A priori the sum of all 4 sizes must be 128 bits. Could you specify the 
error handling when this is not the case? (a choice could be to ignore 
this Sub-Sub-TLV; but given the error handling specified for another 
error, you seem to prefer to ignore the whole parent TLV.


##PP
the sum may not need to be 128, some fields may be advertised as 0 - 
e.g. not all SIDs have arguments.






§9

“ISIS SRv6 SID Structure Sub-Sub-TLV MUST NOT appear more than once in

its parent sub-TLV.If it appears more than once in its parent TLV,

the parent TLV MUST be ignored by the receiver.”

In the first sentence, ‘parent” refers to the sub-TLV.

In the second sentence, ‘parent” refers to the TLV.

I assume that the second sentence should also refers to the parent 
‘sub-TLV’ but I’d prefer this be clarified in the text.



##PP
fixed.






§12.1.1 defines a new IANA registry "sub-sub-TLVs for SRv6 End SID sub-TLV"

§12.5 defines a new IANA registry “Sub-Sub-TLVs for SID Sub-TLVs”

Just checking whether both are needed/intended especially as the second 
references section 7.2. (SRv6 End SID sub-TLV)


##PP
this was a duplication, I have removed the part from the section 12.1.1.



Nits:

==

Idnitsreports 1 error & 1 warning that seem valid : 
https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-lsr-isis-srv6-extensions-04.txt


---

Page header is " draft-bashandy-isis-srv6-extensions". Probably a better 
name could be found for the RFC. E.g. IS-IS extensions for SRv6.


##PP
fixed



---

Proposed

OLD:a combination of SID's

NEW: a combination of SIDs

---

OLD: is received in both in a

NEW: is received in both a

--

OLD: the this draft

NEW: this draft


##PP
fixed all of the above.

thanks,
Peter




-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Wednesday, January 22, 2020 1:15 AM
To: lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps; Acee Lindem (acee)
Subject: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
draft-ietf-lsr-isis-srv6-extensions


https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

Authors please indicate if you aware of any other IPR beyond what is posted:

https://datatracker.ietf.org/ipr/3796/

Thanks,

Chris & Acee.

___

Lsr mailing list

Lsr@ietf.org

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

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Zhuangshunwan]

Support.

Thanks,
Shunwan

From:Christian Hopps mailto:cho...@chopps.org>>
To:lsr mailto:lsr@ietf.org>>
Cc:lsr-ads mailto:lsr-...@ietf.org>>;Christian Hopps 
mailto:cho...@chopps.org>>;Acee Lindem (acee) 
mailto:a...@cisco.com>>
Date:2020-01-22 08:15:24
Subject:[Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
draft-ietf-lsr-isis-srv6-extensions

  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

Authors please indicate if you aware of any other IPR beyond what is posted:

  https://datatracker.ietf.org/ipr/3796/

Thanks,
Chris & Acee.
___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Lizhenbin]

I support the last call. There have been multiple implementations and 
deployment. The solution is stable and the draft is well written.

Best Regards,
Zhenbin (Robin)

--
李振斌 Li Zhenbin
Mobile: +86-13651017745/+968-91797068
Email: lizhen...@huawei.com<mailto:lizhen...@huawei.com>

发件人：Christian Hopps 
收件人：lsr 
抄 送：lsr-ads ;Christian Hopps ;Acee Lindem 
(acee) 
时 间：2020-01-22 08:15:23
主 题：[Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
draft-ietf-lsr-isis-srv6-extensions

  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

Authors please indicate if you aware of any other IPR beyond what is posted:

  https://datatracker.ietf.org/ipr/3796/

Thanks,
Chris & Acee.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Yingzhen Qu]

Support.

Thanks,
Yingzhen

From: Lsr  on behalf of "Xiejingrong (Jingrong)" 

Date: Friday, January 24, 2020 at 7:14 AM
To: Christian Hopps , lsr 
Cc: lsr-ads , Christian Hopps , "Acee 
Lindem (acee)" 
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
Resent-From: 


support.
From:Christian Hopps 
To:lsr 
Cc:lsr-ads ;Christian Hopps ;Acee Lindem 
(acee) 
Date:2020-01-22 08:15:24
Subject:[Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
draft-ietf-lsr-isis-srv6-extensions

  
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-isis-srv6-extensions%2F=02%7C01%7Cyingzhen.qu%40futurewei.com%7Ce16a34ad6ccd4bfe2e8408d7a0e02761%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637154756947270304=4WygaZUoZRSYWVjsXhlRVI8LxDEYQnubLQmPrgjRPfA%3D=0>

Authors please indicate if you aware of any other IPR beyond what is posted:

  
https://datatracker.ietf.org/ipr/3796/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fipr%2F3796%2F=02%7C01%7Cyingzhen.qu%40futurewei.com%7Ce16a34ad6ccd4bfe2e8408d7a0e02761%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637154756947280299=qpxYJquhg7NjpZxMZyYcDizQwoKSnstbjjBPXrXWhb0%3D=0>

Thanks,
Chris & Acee.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr=02%7C01%7Cyingzhen.qu%40futurewei.com%7Ce16a34ad6ccd4bfe2e8408d7a0e02761%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637154756947280299=gsSqx7MWTUWuTmQ0tG3YeJEZg2olB5dR7RcfguwsupE%3D=0>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Les Ginsberg (ginsberg)]

Bruno -

ISO 10589 defines/advertises a system ID length which can be 1-8 octets.
ISO 10589 also requires that every router in the domain use the same ID length:

7.3.15.1 Action on receipt of a link state PDU

4)If the ID Length field of the PDU is not equal to the value of 
the IS's routeingDomainIDLength, the PDU shall be discarded and an 
iDFieldLengthMismatch event generated.

As previously stated, from a practical standpoint, existing implementations 
only support a length of 6 - which is why RFC 5305 definition "works". But if 
there was ever a need to support an ID length other than 6, the TLV definition 
defined in RFC 5305 would still work - it would just have to be reinterpreted 
to use the ID length defined for the domain.

In most specifications, we try to use ID Length so this issue is more 
explicitly addressed and I think that is the more preferred method. So I do not 
agree that we should use "6 explicitly".

If you want to pursue a clarification regarding RFC 5305 in this regard you may 
- though I hope we could agree this isn't a high priority issue.

   Les



From: bruno.decra...@orange.com 
Sent: Friday, January 24, 2020 9:19 AM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps ; Acee Lindem (acee) 

Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Les,


From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, January 24, 2020 5:39 PM
To: DECRAENE Bruno TGI/OLN; lsr@ietf.org<mailto:lsr@ietf.org>
Cc: lsr-...@ietf.org<mailto:lsr-...@ietf.org>; Christian Hopps; Acee Lindem 
(acee)
Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Bruno -

Regarding


§8.2
"System-ID: 6 octets of IS-IS System-ID of length "ID Length" as defined in 
[ISO10589]. »

The field seems of fixed length (6 octets) while the encoded System ID seems to 
be of a variable length. If so, wouldn't it be useful to indicate how a System 
ID of a length shorter than 6 octets is encoded? (in most or least significant 
octets?).


It is well known that - although ISO 10589 supports a system-id length between 
1-8 octets - in practice the length 6 is always used. And of course all nodes 
have to agree to use the same length.
[Bruno] Just to clarify, I was asking for consistency between the length of the 
field ('6 octets') and the lengths of its content ('  "ID Length" as defined in 
[ISO10589] ').

The comparable text from RFC 8667 Section 2.2.2 says:

"Neighbor System-ID:  IS-IS System-ID of length "ID Length" as
   defined in [ISO10589]."

I suggest that the text in this draft be modified to match this - and the ASCII 
art text changes "6 octets" to "ID Length octets" - again matching RFC 8667.

[Bruno] Looks better as this is consistent. I feel that it could be even better 
as I still see two options:

  *   a) If the length of the System ID is fixed to 6, I think that this needs 
to be indicated in the draft (rather than "as defined in [ISO10589]" which 
allows for a variable length).
  *   b) If the length of the System ID is variable "as defined in [ISO10589]", 
then I don't see how the receiver can know this length and successfully parse 
the sub-TLV, except may be by looking at another field in the LSP

Looking at RFC 5305, it seems to define/hard code a length of 6 for the ID, 
which is aligned with option "a" and what is much probably meant in this draft. 
https://tools.ietf.org/html/rfc5305#section-3
(That been said RFC 5306 (i.e. next RFC) , which you co-author, seems to allow 
for a variable length)


Hence I would rather propose  "System-ID: 6 octets of IS-IS System-ID" as per 
option "a". But I'm also fine with option "b" if you want.

--Bruno

I think there is no need to spend time discussing lengths other than 6.
Would you agree?


   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Sent: Friday, January 24, 2020 7:25 AM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Cc: lsr-...@ietf.org<mailto:lsr-...@ietf.org>; Christian Hopps 
mailto:cho...@chopps.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions


Hi authors, WG,



I've re-read the draft. Please find below some minor comments and nits.



Best regards,

--Bruno



Minors:

==

" A node indicates that it has support for SRv6 by advertising a new SRv6 
Capabilities sub-TLV"

I'm not completely certain that "support for SRv6" is perfectly defined. Do you 
have a reference? Otherwise may be "is an SRv6 Segment Endpoint Node" would be 
better.

Cf 
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-3



---

§4.3

"The Maximum H.Encaps MSD Type speci

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[bruno.decraene]

Les,


From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, January 24, 2020 5:39 PM
To: DECRAENE Bruno TGI/OLN; lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps; Acee Lindem (acee)
Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Bruno -

Regarding


§8.2
"System-ID: 6 octets of IS-IS System-ID of length "ID Length" as defined in 
[ISO10589]. »

The field seems of fixed length (6 octets) while the encoded System ID seems to 
be of a variable length. If so, wouldn't it be useful to indicate how a System 
ID of a length shorter than 6 octets is encoded? (in most or least significant 
octets?).


It is well known that - although ISO 10589 supports a system-id length between 
1-8 octets - in practice the length 6 is always used. And of course all nodes 
have to agree to use the same length.
[Bruno] Just to clarify, I was asking for consistency between the length of the 
field ('6 octets') and the lengths of its content ('  "ID Length" as defined in 
[ISO10589] ').

The comparable text from RFC 8667 Section 2.2.2 says:

"Neighbor System-ID:  IS-IS System-ID of length "ID Length" as
   defined in [ISO10589]."

I suggest that the text in this draft be modified to match this - and the ASCII 
art text changes "6 octets" to "ID Length octets" - again matching RFC 8667.

[Bruno] Looks better as this is consistent. I feel that it could be even better 
as I still see two options:

-  a) If the length of the System ID is fixed to 6, I think that this 
needs to be indicated in the draft (rather than "as defined in [ISO10589]" 
which allows for a variable length).

-  b) If the length of the System ID is variable "as defined in 
[ISO10589]", then I don't see how the receiver can know this length and 
successfully parse the sub-TLV, except may be by looking at another field in 
the LSP

Looking at RFC 5305, it seems to define/hard code a length of 6 for the ID, 
which is aligned with option "a" and what is much probably meant in this draft. 
https://tools.ietf.org/html/rfc5305#section-3
(That been said RFC 5306 (i.e. next RFC) , which you co-author, seems to allow 
for a variable length)


Hence I would rather propose  "System-ID: 6 octets of IS-IS System-ID" as per 
option "a". But I'm also fine with option "b" if you want.

--Bruno
I think there is no need to spend time discussing lengths other than 6.
Would you agree?


   Les


From: Lsr  On Behalf Of bruno.decra...@orange.com
Sent: Friday, January 24, 2020 7:25 AM
To: lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps ; Acee Lindem (acee) 

Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions


Hi authors, WG,



I've re-read the draft. Please find below some minor comments and nits.



Best regards,

--Bruno



Minors:

==

" A node indicates that it has support for SRv6 by advertising a new SRv6 
Capabilities sub-TLV"

I'm not completely certain that "support for SRv6" is perfectly defined. Do you 
have a reference? Otherwise may be "is an SRv6 Segment Endpoint Node" would be 
better.

Cf 
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-3



---

§4.3

"The Maximum H.Encaps MSD Type specifies the maximum number of SIDs  that can 
be included as part of the "H.Encaps" behavior"



This is not crystal clear to me when the "reduced encapsulation" is used. In 
such case we have:

a) the number of SID included (N)

b) the number of SID included in the SRH (N-1)



Could you clarify which one you are referring to?



I assume that this is "b" given the text:

"If the advertised value is zero then the router can apply H.Encaps only by 
encapsulating the incoming packet in another  IPv6 header without SRH the same 
way IPinIP encapsulation is performed."

But to avoid interop issue, I'd prefer the spec to be non ambiguous. (typically 
by saying "SIDs in a SRH" as indicated in §4.4



---

§4.2

"in  the top SRH in an SRH stack to which the router can apply "PSP" or  USP" 
as defined in [I-D.ietf-spring-srv6-network-programming]  flavors"



[I-D.ietf-spring-srv6-network-programming] does not define (anymore) "SRH 
stack", nor "top SRH". Please remove those two terms.



---

§4.4



"  If the advertised value is zero or no value is advertised

  then it is assumed that the router cannot apply

  "End.DX6" or "End.DT6" behaviors if the extension

  header right underneath the outer IPv6 header is an SRH."



There is no requirement for the SRH to be "right underneath the outer IPv6 
header".

Cf https://tools.ietf.org/html/rfc8200#section-4.1



Please clarify what is meant precisely. E.g.:

a) if there is an SRH

b) if there is a IPv6 rou

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Les Ginsberg (ginsberg)]

I support progressing this draft.

   Les

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Tuesday, January 21, 2020 4:15 PM
> To: lsr@ietf.org
> Cc: lsr-...@ietf.org; Christian Hopps ; Acee Lindem
> (acee) 
> Subject: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
> 
> This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
> draft-ietf-lsr-
> isis-srv6-extensions
> 
>   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/
> 
> Authors please indicate if you aware of any other IPR beyond what is posted:
> 
>   https://datatracker.ietf.org/ipr/3796/
> 
> Thanks,
> Chris & Acee.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Les Ginsberg (ginsberg)]

Bruno -

Regarding


§8.2
"System-ID: 6 octets of IS-IS System-ID of length "ID Length" as defined in 
[ISO10589]. »

The field seems of fixed length (6 octets) while the encoded System ID seems to 
be of a variable length. If so, wouldn't it be useful to indicate how a System 
ID of a length shorter than 6 octets is encoded? (in most or least significant 
octets?).


It is well known that - although ISO 10589 supports a system-id length between 
1-8 octets - in practice the length 6 is always used. And of course all nodes 
have to agree to use the same length.

The comparable text from RFC 8667 Section 2.2.2 says:

"Neighbor System-ID:  IS-IS System-ID of length "ID Length" as
   defined in [ISO10589]."

I suggest that the text in this draft be modified to match this - and the ASCII 
art text changes "6 octets" to "ID Length octets" - again matching RFC 8667.

I think there is no need to spend time discussing lengths other than 6.
Would you agree?

   Les


From: Lsr  On Behalf Of bruno.decra...@orange.com
Sent: Friday, January 24, 2020 7:25 AM
To: lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps ; Acee Lindem (acee) 

Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions


Hi authors, WG,



I've re-read the draft. Please find below some minor comments and nits.



Best regards,

--Bruno



Minors:

==

" A node indicates that it has support for SRv6 by advertising a new SRv6 
Capabilities sub-TLV"

I'm not completely certain that "support for SRv6" is perfectly defined. Do you 
have a reference? Otherwise may be "is an SRv6 Segment Endpoint Node" would be 
better.

Cf 
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-3



---

§4.3

"The Maximum H.Encaps MSD Type specifies the maximum number of SIDs  that can 
be included as part of the "H.Encaps" behavior"



This is not crystal clear to me when the "reduced encapsulation" is used. In 
such case we have:

a) the number of SID included (N)

b) the number of SID included in the SRH (N-1)



Could you clarify which one you are referring to?



I assume that this is "b" given the text:

"If the advertised value is zero then the router can apply H.Encaps only by 
encapsulating the incoming packet in another  IPv6 header without SRH the same 
way IPinIP encapsulation is performed."

But to avoid interop issue, I'd prefer the spec to be non ambiguous. (typically 
by saying "SIDs in a SRH" as indicated in §4.4



---

§4.2

"in  the top SRH in an SRH stack to which the router can apply "PSP" or  USP" 
as defined in [I-D.ietf-spring-srv6-network-programming]  flavors"



[I-D.ietf-spring-srv6-network-programming] does not define (anymore) "SRH 
stack", nor "top SRH". Please remove those two terms.



---

§4.4



"  If the advertised value is zero or no value is advertised

  then it is assumed that the router cannot apply

  "End.DX6" or "End.DT6" behaviors if the extension

  header right underneath the outer IPv6 header is an SRH."



There is no requirement for the SRH to be "right underneath the outer IPv6 
header".

Cf https://tools.ietf.org/html/rfc8200#section-4.1



Please clarify what is meant precisely. E.g.:

a) if there is an SRH

b) if there is a IPv6 routing header

c) if there is  an IPv6 extension header

?

.



Given the wording in §4.2, I would suggest "a". However, the technical question 
remains: are those MSD numbers affected by the presence of another IPv6 
extension header (before the SRH)?



---

OLD: This is to prevent inconsistent forwarding entries on SRv6 capable/SRv6 
incapable routers.





I think the below would be clearer

NEW: This is to prevent inconsistent forwarding entries between SRv6 capable 
and SRv6 incapable routers.





§7.1



"

 Type: 27 (Suggested value to be assigned by IANA)



 Length: variable.



 MTID: Multitopology Identifier as defined in 
[RFC5120<https://tools.ietf.org/html/rfc5120>].

 Note that the value 0 is legal."



Personally I would find clearer to move the above text (describing the SRv6 
Locator TLV) just after the Figure of the SRv6 Locator TLV.



That would also allow the removal of "Locator entry:" since as a result the 
text and figures for the local entry would also be grouped together.





§7.1

"Loc-Size: 1 octet. Number of bits in the Locator field."



I think that this is the number of bits of the SRv6 Locator, rather than the 
number of bits of the field.



Proposed NEW: Loc-Size: 1 octet. Number of bits in the SRv6 Locator.



"The Locator is encoded in the minimal number of  octets for the given number 
of bits."

Do we want to define the trailing bits? E.g. MUST be sent as zero and ign

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[bruno.decraene]

, you seem 
to prefer to ignore the whole parent TLV.



§9

"ISIS SRv6 SID Structure Sub-Sub-TLV MUST NOT appear more than once in
   its parent sub-TLV.  If it appears more than once in its parent TLV,
   the parent TLV MUST be ignored by the receiver."



In the first sentence, 'parent" refers to the sub-TLV.

In the second sentence, 'parent" refers to the TLV.

I assume that the second sentence should also refers to the parent 'sub-TLV' 
but I'd prefer this be clarified in the text.



§12.1.1 defines a new IANA registry "sub-sub-TLVs for SRv6 End SID sub-TLV"

§12.5 defines a new IANA registry "Sub-Sub-TLVs for SID Sub-TLVs"



Just checking whether both are needed/intended especially as the second 
references section 7.2. (SRv6 End SID sub-TLV)



Nits:

==

Idnits reports 1 error & 1 warning that seem valid : 
https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-lsr-isis-srv6-extensions-04.txt

---

Page header is " draft-bashandy-isis-srv6-extensions". Probably a better name 
could be found for the RFC. E.g. IS-IS extensions for SRv6.

---

Proposed

OLD:  a combination of SID's

NEW: a combination of SIDs

---

OLD: is received in both in a

NEW: is received in both a

--

OLD: the this draft

NEW: this draft







-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Wednesday, January 22, 2020 1:15 AM
To: lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps; Acee Lindem (acee)
Subject: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions



This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
draft-ietf-lsr-isis-srv6-extensions



  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/



Authors please indicate if you aware of any other IPR beyond what is posted:



  https://datatracker.ietf.org/ipr/3796/



Thanks,

Chris & Acee.

___

Lsr mailing list

Lsr@ietf.org

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

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Xiejingrong (Jingrong)]

support.

From:Christian Hopps 
To:lsr 
Cc:lsr-ads ;Christian Hopps ;Acee Lindem 
(acee) 
Date:2020-01-22 08:15:24
Subject:[Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
draft-ietf-lsr-isis-srv6-extensions

  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

Authors please indicate if you aware of any other IPR beyond what is posted:

  https://datatracker.ietf.org/ipr/3796/

Thanks,
Chris & Acee.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Huaimo Chen]

Support.

Best Regards,
Huaimo

> On Jan 22, 2020, at 1:14 AM, Christian Hopps  wrote:
>
> This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
> draft-ietf-lsr-isis-srv6-extensions
>
>  
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-isis-srv6-extensions%2Fdata=02%7C01%7Chuaimo.chen%40futurewei.com%7C5e71fc305dc84bee96f208d7a0d3d604%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637154704013184727sdata=d%2BFN9%2BxhMfAP06%2FelMEoIYbn3dnKfNcCOKkspuI8DBU%3Dreserved=0
>
> Authors please indicate if you aware of any other IPR beyond what is posted:
>
>  
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fipr%2F3796%2Fdata=02%7C01%7Chuaimo.chen%40futurewei.com%7C5e71fc305dc84bee96f208d7a0d3d604%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637154704013184727sdata=TiWrbHt636eWDWePu6ZKi6g5r447kqdh71kh7GYSOPA%3Dreserved=0
>
> Thanks,
> Chris & Acee.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsrdata=02%7C01%7Chuaimo.chen%40futurewei.com%7C5e71fc305dc84bee96f208d7a0d3d604%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637154704013184727sdata=sUoMkREq%2Bgx1kDEp48P1GJsY8cbmiUC2m83zrhI2Gas%3Dreserved=0

___
Lsr mailing list
Lsr@ietf.org
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsrdata=02%7C01%7Chuaimo.chen%40futurewei.com%7C5e71fc305dc84bee96f208d7a0d3d604%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637154704013184727sdata=sUoMkREq%2Bgx1kDEp48P1GJsY8cbmiUC2m83zrhI2Gas%3Dreserved=0
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[stefano previdi]

As contributor, I do support the draft and I’m not aware of any undisclosed IPR.

Thanks.
s.



> On Jan 22, 2020, at 1:14 AM, Christian Hopps  wrote:
> 
> This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
> draft-ietf-lsr-isis-srv6-extensions
> 
>  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/
> 
> Authors please indicate if you aware of any other IPR beyond what is posted:
> 
>  https://datatracker.ietf.org/ipr/3796/
> 
> Thanks,
> Chris & Acee.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Clarence Filsfils (cfilsfil)]

I am not aware of any undisclosed IPR related to this draft.

Cheers,
Clarence

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Wednesday, January 22, 2020 01:15
> To: lsr@ietf.org
> Cc: lsr-...@ietf.org; Christian Hopps ; Acee Lindem
> (acee) 
> Subject: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
> 
> This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
> draft-ietf-lsr-
> isis-srv6-extensions
> 
>   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/
> 
> Authors please indicate if you aware of any other IPR beyond what is posted:
> 
>   https://datatracker.ietf.org/ipr/3796/
> 
> Thanks,
> Chris & Acee.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Ketan Talaulikar (ketant)]

Support. As a contributor, I am not aware of any undisclosed IPR related to 
this draft.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of Paul Wells (pauwells)
Sent: 24 January 2020 06:10
To: cho...@chopps.org; lsr@ietf.org
Cc: lsr-...@ietf.org; Acee Lindem (acee) 
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Support. Not aware of any undisclosed IPR.

Paul

On Tue, 2020-01-21 at 19:14 -0500, Christian Hopps wrote:
> This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
> draft-ietf-lsr-isis-srv6-extensions
> 
>   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/
> 
> Authors please indicate if you aware of any other IPR beyond what is posted:
> 
>   https://datatracker.ietf.org/ipr/3796/
> 
> Thanks,
> Chris & Acee.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Huzhibo]

Support. Not aware of any undisclosed IPR.

Zhibo

--
胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: huzh...@huawei.com<mailto:huzh...@huawei.com>

发件人：Christian Hopps 
收件人：lsr 
抄 送：lsr-ads ;Christian Hopps ;Acee Lindem 
(acee) 
时 间：2020-01-22 08:15:23
主 题：[Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
draft-ietf-lsr-isis-srv6-extensions

  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

Authors please indicate if you aware of any other IPR beyond what is posted:

  https://datatracker.ietf.org/ipr/3796/

Thanks,
Chris & Acee.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Paul Wells (pauwells)]

Support. Not aware of any undisclosed IPR.

Paul

On Tue, 2020-01-21 at 19:14 -0500, Christian Hopps wrote:
> This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
> draft-ietf-lsr-isis-srv6-extensions
> 
>   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/
> 
> Authors please indicate if you aware of any other IPR beyond what is posted:
> 
>   https://datatracker.ietf.org/ipr/3796/
> 
> Thanks,
> Chris & Acee.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Mankamana Mishra (mankamis)]

Support progressing this document. 

On 1/21/20, 4:17 PM, "Lsr on behalf of Christian Hopps"  wrote:

This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
draft-ietf-lsr-isis-srv6-extensions

  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

Authors please indicate if you aware of any other IPR beyond what is posted:

  https://datatracker.ietf.org/ipr/3796/

Thanks,
Chris & Acee.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Zafar Ali (zali)]

Dear chairs and the WG,

I have reviewed the draft (now and during its progression) and believe it is 
ready for publication.

Thanks

Regards … Zafar

From: Lsr  on behalf of Christian Hopps 

Date: Tuesday, January 21, 2020 at 7:15 PM
To: "lsr@ietf.org" 
Cc: "lsr-...@ietf.org" , Christian Hopps , 
"Acee Lindem (acee)" 
Subject: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
draft-ietf-lsr-isis-srv6-extensions

  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

Authors please indicate if you aware of any other IPR beyond what is posted:

  https://datatracker.ietf.org/ipr/3796/

Thanks,
Chris & Acee.
___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Acee Lindem (acee)]

Speaking as WG member, 

I have reviewed revisions of this draft and support publication.

Thanks,
Acee

On 1/21/20, 7:15 PM, "Christian Hopps"  wrote:

This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
draft-ietf-lsr-isis-srv6-extensions

  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

Authors please indicate if you aware of any other IPR beyond what is posted:

  https://datatracker.ietf.org/ipr/3796/

Thanks,
Chris & Acee.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[bruno.decraene]

Chris,

I'm not aware of non-disclosed IPR.

Regards,
--Bruno
-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Wednesday, January 22, 2020 1:15 AM
To: lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps; Acee Lindem (acee)
Subject: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
draft-ietf-lsr-isis-srv6-extensions

  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

Authors please indicate if you aware of any other IPR beyond what is posted:

  https://datatracker.ietf.org/ipr/3796/

Thanks,
Chris & Acee.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Peter Psenak]

Hi Chris,

On 22/01/2020 01:14, Christian Hopps wrote:

This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
draft-ietf-lsr-isis-srv6-extensions >
   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

Authors please indicate if you aware of any other IPR beyond what is posted:

   https://datatracker.ietf.org/ipr/3796/


I'm not aware of any other IPRs beyond what is posted.

thanks,
Peter


Thanks,
Chris & Acee.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr




___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Christian Hopps]

This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
draft-ietf-lsr-isis-srv6-extensions

  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

Authors please indicate if you aware of any other IPR beyond what is posted:

  https://datatracker.ietf.org/ipr/3796/

Thanks,
Chris & Acee.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr