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