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

[Peter Psenak <[e-mail]>]

Hi Bruno,

On 28/01/2020 18:05, [e-mail] 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:[e-mail]]
>> Sent: Monday, January 27, 2020 1:43 PM
>> To: DECRAENE Bruno TGI/OLN; [e-mail]
>> Cc: [e-mail]; 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, [e-mail] 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:[e-mail]] On Behalf Of Christian Hopps
>>>> Sent: Wednesday, January 22, 2020 1:15 AM
>>>> To: [e-mail]
>>>> Cc: [e-mail]; 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
>>>>
>>>> [e-mail]
>>>>
>>>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
> 
>