Re: [Lsr] IS-IS over TCP
On Tue, Nov 06, 2018 at 10:51:33AM +0700, tony...@tony.li wrote: > > Per the WG meeting, discussing on the list: > > This is good work and I support it. Ditto. > I would remind folks that TCP is NOT the only transport protocol available > and that perhaps we should be considering QUIC while we’re at it. In > particular, flooding is a (relatively) low bandwidth operation in the > modern network and we could avoid slow-start issues by using QUIC. I'm ambivalent of the transport, but agree that TCP shouldn't be the default answer. My concerns that I tried raising via jabber summarize roughly as follows: - TCP is prone to interesting backpressure issues, typically as a result of packet loss or slow receivers. - TCP timers can react poorly in some environments where you may want time sensitive things. This includes something as long as 3 second BGP hold timers. - IGPs have a lot of interesting timer hacks to try to ensure that a given domain has a consistent database prior to running an SPF. In the face of "stuck" flooding due to backpressure or other things, some of these may need to be revisited. It's been over a year since I looked at QUIC. I agree with Tony that a number of the properties it had on my last read are desirable. I'd suggest that its behavior (especially timers) in the event of packet loss should be given a look at based on the comments above. - Jeff ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] IS-IS over TCP
Thanks, Tony. We picked TCP because every router on the planet already has a TCP stack in it. That made it the obvious choice. Our draft described a TVL in the IIHs to indicate a router's ability to use TCP for flooding. That TLV has several sub-TVLs. 1) the TCP port-number 2) an IPv4 address 3) and/or an IPv6 address We can change the first sub-TVL so that it indicates: 1) 1 or 2 bytes indicating what protocol to use 2) the remainder of the sub-TLV is an indicator what port-number or other identifier to use to connect over that protocol. This way we can start improving IS-IS with TCP today. And add/replace it with other protocols in the future. henk. tony...@tony.li schreef op 2018-11-06 04:51: Per the WG meeting, discussing on the list: This is good work and I support it. I would remind folks that TCP is NOT the only transport protocol available and that perhaps we should be considering QUIC while we’re at it. In particular, flooding is a (relatively) low bandwidth operation in the modern network and we could avoid slow-start issues by using QUIC. Tony ___ 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] IS-IS over TCP
Per the WG meeting, discussing on the list: This is good work and I support it. I would remind folks that TCP is NOT the only transport protocol available and that perhaps we should be considering QUIC while we’re at it. In particular, flooding is a (relatively) low bandwidth operation in the modern network and we could avoid slow-start issues by using QUIC. Tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Publication has been requested for draft-ietf-lsr-isis-rfc7810bis-02
Acee Lindem has requested publication of draft-ietf-lsr-isis-rfc7810bis-02 as Proposed Standard on behalf of the LSR working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc7810bis/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] IPR Call for "YANG Data Model for OSPF Protocol" - draft-ietf-ospf-yang-17
I’m not aware of any IPR associated with this document. Dean > On Nov 5, 2018, at 4:36 PM, Acee Lindem (acee) wrote: > > Authors and Contributors, > > Please confirm that any and all appropriate IPR disclosures required for full > conformance with the provisions of BCP 78 and BCP 79 have already been filed. > If not, explain why? Each author/contributor should respond explicitly to > this list. > > Thanks, > Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] IPR Call for "YANG Data Model for OSPF Protocol" - draft-ietf-ospf-yang-17
Authors and Contributors, Please confirm that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Each author/contributor should respond explicitly to this list. Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] I-D Action: draft-ietf-ospf-ospfv3-segment-routing-extensions-17.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : OSPFv3 Extensions for Segment Routing Authors : Peter Psenak Stefano Previdi Filename: draft-ietf-ospf-ospfv3-segment-routing-extensions-17.txt Pages : 27 Date: 2018-11-05 Abstract: Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the OSPFv3 extensions required for Segment Routing with MPLS data plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-segment-routing-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-routing-extensions-17 https://datatracker.ietf.org/doc/html/draft-ietf-ospf-ospfv3-segment-routing-extensions-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-ospfv3-segment-routing-extensions-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Secdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16
Hi Yaron, thanks for your comments, please see inline: On 04/11/18 16:38 , Yaron Sheffer wrote: Reviewer: Yaron Sheffer Review result: Has Nits Summary: document has non-security related nits. Details * The definition of "segment" is different here from the one used in the architecture RFC. The RFC is more abstract, quoting: A node steers a packet through an ordered list of instructions, called "segments". Whereas here a segment is simply a sub-path. This is confusing to a non-expert, and perhaps indicates a change in the group's thinking. the definition in this draft relates to segment as used by IGPs, in which case a segment represents the sub-path. There are other segments outside of IGPs which can represent other things, but they are not covered by this draft. * SID/Label Sub-TLV: is it Mandatory? If so, please point it out. SID/Label Sub-TLV is not advertised on its own. It is advertised as a sub-TLV of the: 3.2. SID/Label Range TLV 3.3. SR Local Block TLV Both of these section specify that SID/Label Sub-TLV MUST be included. * "The SR-Algorithm TLV is optional" - I find this sentence confusing. Maybe replace by "The SR-Algorithm TLV is mandatory for routers that implement segment routing"? the text says: "If the SR-Algorithm TLV is not advertised by the node, such node is considered as not being segment routing capable." Isn't that sufficient? * The reference under "IGP Algorithm Type" registry should be to the IANA registry itself, not to the I-D that defines it. (In particular since the IANA registry has already been established, https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types). I got another comment from Opsdir last call review to include the I-D that defined it. I Added them both, hopefully that satisfy everybody. * OSPFv3 Extended Prefix Range TLV Flags octet: add the usual incantation about reserved bits. Done. * In general I agree with the reasoning in the Security Considerations. I would like to raise the question if, in addition to mis-routing, this adds a threat of massive denial-of-service on MPLS endpoints, e.g. by allowing an attacker who has OSPF access to introduce routing loops. (This may be completely bogus, I am far from expert with either of these protocols). above is addressed by usage of the usage of the OSPF authentication as described in the security section. thanks, Peter . ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
