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

2020-01-27 Thread Alvaro Retana 
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] IS-IS Requirements for Area Abstraction (Corrected Alias for ADs)

2020-01-27 Thread Acee Lindem (acee) 
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] IS-IS Requirements for Area Abstraction

2020-01-27 Thread Acee Lindem (acee) 
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

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

2020-01-27 Thread Peter Psenak 

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


##PP
done.






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


##PP
done



“The Locator is encoded in the minimal number ofoctets for the given 
number of bits.”


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


##PP
done





§8.1 (idem for §8.2)

I may be missing something…

“All End.X SIDs MUST be a subnet of a Locator with matching topology

and algorithm which is advertised by the same node in an SRv6 Locator

TLV. »

OK.

So what’s the point of advertising a field ‘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

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

2020-01-27 Thread 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
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr