Re: [Lsr] I-D Action: draft-ietf-lsr-isis-srv6-extensions-10.txt
Hi Joel, Please check inline below. -Original Message- From: Lsr On Behalf Of Joel M. Halpern Sent: 25 September 2020 03:18 To: Acee Lindem (acee) ; lsr@ietf.org Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-srv6-extensions-10.txt First, there is a slight confusion in the way I formed the quesiton, but I think it still applies. The piece of this draft is section 9, which advertises the length of the arg portion of the SID. But does not provide specific meanings for specific values. [KT] This is quite appropriate for this draft since it is only specifying a generic SID structure and not associated with any specific behavior. The example of an ARG in the network programming draft does provide part of the explicit interpretation of the ARG. It says that it is a list of k items, each of x bits, where each x bit blob identifies an OIF. [KT] The net-pgm draft in sec 4.12 introduces a specific End.DT2M behavior which includes support for ARG. That said, I am not quite sure about that text in that section which talks about how the ARG bits are formed and what they signify. I believe the ARG in this case is a locally assigned identifier that maps to an ESI so that it can be used for ESI filtering - much the same as an ESI label for split-horizon filtering. I see a comment from one of the ADs on this and I expect that the authors will clarify. This leaves two gaps, and a more general question. 1) How does the receiver know the meanings of the OIF indices so that he can correctly fill them in? 2) The NP draft says that k and x are defined on a per SID basis. But I do not see anywhere in the isis draft to advertise the values of k and x, only arg (which is k*x). [KT] I hope the previous comment explains. The more general question is, is there a requirement we can write down about how receivers will be able to understand ARG fields in general? One can argue that it would belong in the network programming draft; I would prefer not to delay that with a significant technical addition. [KT] I don't believe the handling of ARG is something that can be generalized. It has to be something specific to the behavior that it is associated with. Therefore, each behavior that supports an ARG needs to specify its handling. The net-pgm draft is doing it for End.DT2M and future documents that introduce other behaviors requiring ARG would be expected to the same. Thanks, Ketan There is a related question that I came across while trying to explain this question. END.T must be associated with a forwarding table. I presume this is done by where one puts the END.T (however-many-subs) TLV. But I can not find anything in this draft that says this. There is precisely one reference to End.T in the draft. Thank you, Joel On 9/24/2020 5:25 PM, Acee Lindem (acee) wrote: > H Joel, > > Can you reference the specific section in the IS-IS SRv6 draft you are > commenting on? I seem to remember this discussion but it was at least a month > back, if not more. > > Thanks, > Acee > > On 9/23/20, 6:31 PM, "Lsr on behalf of Joel Halpern" on behalf of j...@joelhalpern.com> wrote: > > The announcement prompted me to look again and think about an > interaction between this and the network programming draft. To be > clear, I am NOT objecting to either this or the network programming > draft. I am just wondering what I am missing. > > The NP draft, and the advertisement mechanism allows a router to > advertise the number of bits for the ARG portion of a SID. > > Q1: The point presumably is to avoid needing to advertise each of the > individual values? > > An example of this is, I think, and ARG for the table selection where > the ARG is the table number for the packet to be looked up in? > > Q2: If so, how does the head end know what table number corresponds to > what meaning?If this requires a separate advertisement there seems > to be no savings. if this requires out-of-band knowledge then we seem > to have lost the benefit of advertising all of this in the routing > protocol. > > I suspect I am simply missing a piece. can someone explain please? > > Thank you, > Joel > > On 9/23/2020 4:40 PM, internet-dra...@ietf.org wrote: > > > > 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 : IS-IS Extension to Support Segment Routing > over IPv6 Dataplane > > Authors : Peter Psenak > >Clarence Filsfils > >Ahmed Bashandy > >Bruno Decraene > >Zhibo Hu > >Filename: draft-ietf-lsr-isis-srv6-extensions-10.txt > >Pages : 25 > >Date
Re: [Lsr] RFC 8918 on Invalid TLV Handling in IS-IS
Authors, Thanks for the swift work on this document. Acee On 9/24/20, 6:19 PM, "Lsr on behalf of rfc-edi...@rfc-editor.org" wrote: A new Request for Comments is now available in online RFC libraries. RFC 8918 Title: Invalid TLV Handling in IS-IS Author: L. Ginsberg, P. Wells, T. Li, T. Przygienda, S. Hegde Status: Standards Track Stream: IETF Date: September 2020 Mailbox:ginsb...@cisco.com, pauwe...@cisco.com, tony...@tony.li, p...@juniper.net, shrad...@juniper.net Pages: 8 Updates:RFC 5305, RFC 6232 I-D Tag:draft-ietf-lsr-isis-invalid-tlv-03.txt URL:https://www.rfc-editor.org/info/rfc8918 DOI:10.17487/RFC8918 The key to the extensibility of the Intermediate System to Intermediate System (IS-IS) protocol has been the handling of unsupported and/or invalid Type-Length-Value (TLV) tuples. Although there are explicit statements in existing specifications, deployment experience has shown that there are inconsistencies in the behavior when a TLV that is disallowed in a particular Protocol Data Unit (PDU) is received. This document discusses such cases and makes the correct behavior explicit in order to ensure that interoperability is maximized. This document updates RFCs 5305 and 6232. This document is a product of the Link State Routing Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ 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] RFC 8918 on Invalid TLV Handling in IS-IS
A new Request for Comments is now available in online RFC libraries. RFC 8918 Title: Invalid TLV Handling in IS-IS Author: L. Ginsberg, P. Wells, T. Li, T. Przygienda, S. Hegde Status: Standards Track Stream: IETF Date: September 2020 Mailbox:ginsb...@cisco.com, pauwe...@cisco.com, tony...@tony.li, p...@juniper.net, shrad...@juniper.net Pages: 8 Updates:RFC 5305, RFC 6232 I-D Tag:draft-ietf-lsr-isis-invalid-tlv-03.txt URL:https://www.rfc-editor.org/info/rfc8918 DOI:10.17487/RFC8918 The key to the extensibility of the Intermediate System to Intermediate System (IS-IS) protocol has been the handling of unsupported and/or invalid Type-Length-Value (TLV) tuples. Although there are explicit statements in existing specifications, deployment experience has shown that there are inconsistencies in the behavior when a TLV that is disallowed in a particular Protocol Data Unit (PDU) is received. This document discusses such cases and makes the correct behavior explicit in order to ensure that interoperability is maximized. This document updates RFCs 5305 and 6232. This document is a product of the Link State Routing Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] I-D Action: draft-ietf-lsr-isis-srv6-extensions-10.txt
First, there is a slight confusion in the way I formed the quesiton, but I think it still applies. The piece of this draft is section 9, which advertises the length of the arg portion of the SID. But does not provide specific meanings for specific values. The example of an ARG in the network programming draft does provide part of the explicit interpretation of the ARG. It says that it is a list of k items, each of x bits, where each x bit blob identifies an OIF. This leaves two gaps, and a more general question. 1) How does the receiver know the meanings of the OIF indices so that he can correctly fill them in? 2) The NP draft says that k and x are defined on a per SID basis. But I do not see anywhere in the isis draft to advertise the values of k and x, only arg (which is k*x). The more general question is, is there a requirement we can write down about how receivers will be able to understand ARG fields in general? One can argue that it would belong in the network programming draft; I would prefer not to delay that with a significant technical addition. There is a related question that I came across while trying to explain this question. END.T must be associated with a forwarding table. I presume this is done by where one puts the END.T (however-many-subs) TLV. But I can not find anything in this draft that says this. There is precisely one reference to End.T in the draft. Thank you, Joel On 9/24/2020 5:25 PM, Acee Lindem (acee) wrote: H Joel, Can you reference the specific section in the IS-IS SRv6 draft you are commenting on? I seem to remember this discussion but it was at least a month back, if not more. Thanks, Acee On 9/23/20, 6:31 PM, "Lsr on behalf of Joel Halpern" wrote: The announcement prompted me to look again and think about an interaction between this and the network programming draft. To be clear, I am NOT objecting to either this or the network programming draft. I am just wondering what I am missing. The NP draft, and the advertisement mechanism allows a router to advertise the number of bits for the ARG portion of a SID. Q1: The point presumably is to avoid needing to advertise each of the individual values? An example of this is, I think, and ARG for the table selection where the ARG is the table number for the packet to be looked up in? Q2: If so, how does the head end know what table number corresponds to what meaning?If this requires a separate advertisement there seems to be no savings. if this requires out-of-band knowledge then we seem to have lost the benefit of advertising all of this in the routing protocol. I suspect I am simply missing a piece. can someone explain please? Thank you, Joel On 9/23/2020 4:40 PM, internet-dra...@ietf.org wrote: > > 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 : IS-IS Extension to Support Segment Routing over IPv6 Dataplane > Authors : Peter Psenak >Clarence Filsfils >Ahmed Bashandy >Bruno Decraene >Zhibo Hu > Filename: draft-ietf-lsr-isis-srv6-extensions-10.txt > Pages : 25 > Date: 2020-09-23 > > Abstract: > Segment Routing (SR) allows for a flexible definition of end-to-end > paths by encoding paths as sequences of topological sub-paths, called > "segments". Segment routing architecture can be implemented over an > MPLS data plane as well as an IPv6 data plane. This draft describes > the IS-IS extensions required to support Segment Routing over an IPv6 > data plane. > > ___ 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] I-D Action: draft-ietf-lsr-isis-srv6-extensions-10.txt
H Joel, Can you reference the specific section in the IS-IS SRv6 draft you are commenting on? I seem to remember this discussion but it was at least a month back, if not more. Thanks, Acee On 9/23/20, 6:31 PM, "Lsr on behalf of Joel Halpern" wrote: The announcement prompted me to look again and think about an interaction between this and the network programming draft. To be clear, I am NOT objecting to either this or the network programming draft. I am just wondering what I am missing. The NP draft, and the advertisement mechanism allows a router to advertise the number of bits for the ARG portion of a SID. Q1: The point presumably is to avoid needing to advertise each of the individual values? An example of this is, I think, and ARG for the table selection where the ARG is the table number for the packet to be looked up in? Q2: If so, how does the head end know what table number corresponds to what meaning?If this requires a separate advertisement there seems to be no savings. if this requires out-of-band knowledge then we seem to have lost the benefit of advertising all of this in the routing protocol. I suspect I am simply missing a piece. can someone explain please? Thank you, Joel On 9/23/2020 4:40 PM, internet-dra...@ietf.org wrote: > > 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 : IS-IS Extension to Support Segment Routing over IPv6 Dataplane > Authors : Peter Psenak >Clarence Filsfils >Ahmed Bashandy >Bruno Decraene >Zhibo Hu > Filename: draft-ietf-lsr-isis-srv6-extensions-10.txt > Pages : 25 > Date: 2020-09-23 > > Abstract: > Segment Routing (SR) allows for a flexible definition of end-to-end > paths by encoding paths as sequences of topological sub-paths, called > "segments". Segment routing architecture can be implemented over an > MPLS data plane as well as an IPv6 data plane. This draft describes > the IS-IS extensions required to support Segment Routing over an IPv6 > data plane. > > ___ 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] some doubt about RFC 5185 (Multi Area Adjacency)
Hi Meicong, From: Lsr on behalf of meicong Date: Thursday, September 24, 2020 at 2:23 AM To: "lsr@ietf.org" Cc: Huzhibo , "Jiangyu (China)" Subject: [Lsr] some doubt about RFC 5185 (Multi Area Adjacency) Hi ALL, About rfc5185 OSPF Multi-Area Adjacency section 2.7 Advertising Multi-Area Adjacencies: Link ID = Remote's Router ID I have the following questions: 1、I'm not sure whether “Neighbor's IP Address” means “local interface IP address” or “remote interface IP address”. 2、If it is remote interface IP address， why not use local interface IP address, Any special considerations? In looking at this again, I believe using the remote interface IP address is unnecessary since the interface area ID can be used to disambiguate the usage for multiple adjacencies. Thanks, Acee Thanks, In section 2.7， Link Data = Neighbor's IP Address 2.7. Advertising Multi-Area Adjacencies Multi-area adjacencies are announced as point-to-point links. Once the router's multi-area adjacency reaches the FULL state, it will be added as a link type 1 to the Router Link State Advertisement (LSA) with: Link ID = Remote's Router ID Link Data = Neighbor's IP Address or IfIndex (if the underlying interface is unnumbered). rfc5185 OSPF Multi-Area Adjacency ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
