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.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

Re: [Lsr] IS-IS Requirements for Area Abstraction (Corrected Alias for ADs)

[Tony Przygienda]

please do not co-mingle hierarchical ISIS and flood reduction drafts into
this discussion. Albeit seemingly related the ttz/abstract/flood-reflector
drafts solve a different, valid problem of multiple large operators that
hierachical,flood-reduce cannot solve albeit they can be used @ the same
time. RFC1925 section 5

thanks

--- tony

On Mon, Jan 27, 2020 at 11:42 AM Alvaro Retana 
wrote:

> FYI…
>
> Because I am one of the co-authors of draft-chen-isis-ttz, I am recusing
> myself from this discussion.  Martin will be the responsible AD for it,
> should one be needed.
>
> Alvaro.
>
> On January 27, 2020 at 1:27:13 PM, Acee Lindem (acee) (a...@cisco.com)
> wrote:
>
> Speaking as WG Co-chair:
>
>
>
> At IETF 107, we had a protracted discussion of several drafts having  goal
> of reducing the amount of link-state information that must be flooded into
> the level-2 area. We have two drafts that do this essentially via
> abstraction of the level-1 areas. These are:
>
>
>
> https://www.ietf.org/id/draft-li-lsr-isis-area-proxy-01.txt
>
> https://www.ietf.org/id/draft-chen-isis-ttz-07.txt
>
>
>
> There are various reasons why these drafts can’t consolidated involving
> both IPR and government restrictions. Refer to
> https://datatracker.ietf.org/meeting/106/materials/minutes-106-lsr-00 for
> the complete discussion.
>
>
>
> We have another draft that also reduces the amount of link-state
> information each IS-IS router must maintain but using IS-IS reflectors.
> This is slightly different but also avoids leaking all the level-1 area
> link-state to the level-2 area.
>
>
>
> https://www.ietf.org/id/draft-przygienda-lsr-flood-reflection-01.txt
>
>
>
> Given the amount of overlap and the conflicts amongst these drafts, the
> chairs/Ads are now asking whether there is a really a strong requirement to
> advance one or more of these documents. Especially given that we are
> already moving forward with both IS-IS/OSPF flooding reductions and the
> Hierarchal IS-IS work. Additionally,  we anticipate we’ll reach an impasse
> in consolidating these drafts. We’d really like to hear from the operators
> that would deploy these mechanisms.
>
>
>
> Thanks,
> Acee and Chris
>
>
>
>
>
> ___
> 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 Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Zhuangshunwan]

Support.

Thanks,
Shunwan

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Friday, January 24, 2020 4:25 AM
To: lsr@ietf.org
Cc: draft-li-lsr-ospfv3-srv6-extensi...@ietf.org; lsr-...@ietf.org; Christian 
Hopps ; Acee Lindem (acee) 
Subject: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hi LSR WG and Draft Authors,

The authors originally requested adoption back @ 105; however, some comments 
were received and new version was produced. Moving forward...

This begins a 2 week WG adoption poll for the following draft:

  https://datatracker.ietf.org/doc/draft-li-lsr-ospfv3-srv6-extensions/
 
Please indicate your support or objection by Feb 6, 2020.

Authors, please respond indicating whether you are aware of any IPR that 
applies to this draft.

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 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 to be assigned by IANA)

Length: variable.

MTID: Multitopology Identifier as defined in [RFC5120  
].

Note that the value 0 is legal.”

Personally I would find clearer to move the above text (describing the
SRv6 Lo

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
> > 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 route