Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 7 Jan 2020 09:16:57 +0000

Hi Adrian,

Happy New Year.
Please see inline.

Many thanks for your comments,
Pablo.

-----Original Message-----
From: Adrian Farrel <[email-masked]>
Organisation: Old Dog Consulting
Reply to: "[email-masked]" <[email-masked]>
Date: Friday, 27 December 2019 at 20:29
To: "Pablo Camarillo (pcamaril)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: WGLC - draft-ietf-spring-srv6-network-programming

    Thanks Pablo and Happy Imminent New Year.
    
    > I have reviewed your suggested changes and incorporated them
    > in the latest revision of the document. 
    
    Great. I will try to pull that and review it soon.
    
    > Please see below inline for more detail.
    
    [snipped]
         
        >> 4.1
        >>
        >> I was surprised by...
        >>
        >>  S01. When an SRH is processed {
        >>  S02.   If (Segments Left == 0) {
        >>  S03.      Send an ICMP Parameter Problem message to the Source Address
        >>               Code TBD-SRH (SR Upper-layer Header Error),
        >>               Pointer set to the offset of the upper-layer header,
        >>               interrupt packet processing and discard the packet
        >>  S04.   }
        >>  S05.   If (IPv6 Hop Limit <= 1) {
        >>  S06.      Send an ICMP Time Exceeded message to the Source Address,
        >>               Code 0 (Hop limit exceeded in transit),
        >>               interrupt packet processing and discard the packet
        >>  S07.   }
        >>
        >> Are you sure that Hop Limit processing is left so late? Isn't it one of
        >> the first things done with a packet before even the SRH is discovered to
        >> be present?
        >
        > PC: Is there any difference on the hop limit check if I do it two lines earlier? 
        > I believe that the end result is the same.
         
        It makes a difference which ICMP error is sent. I would argue that you shouldn't be looking at the SRH of a packet when the Hop Limit has expired.
    
    PC: I've checked with the SRH draft and the ICMP check is the last check happening in the pseudocode. I would tend to agree that this should be the last thing done once you have determined that the packet needs to be forwarded. 
    
    AF: So, just to check I understand what you are saying. If a packet arrives with Hop Limit already at zero you would still look inside the SRH?

PC: As per RFC8200, if a packet arrives with Hop Limit equal to zero, you process the packet normally.
Then, when you attempt to forward it, if Hop Limit is zero, then you discard the packet.
This makes a difference when you are the last segment (like End.DX4).
      
        >> 4.1 (and other sections)
        >> 
        >> I spent rather too much time trying to work out
        >> 
        >>  S08.   max_LE = (Hdr Ext Len / 2) - 1
        >>  S09.   If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
        >> 
        >> As far as I can see, for an SRH,
        >> 
        >>   Hdr Ext Len = 7 + (16 * (Last Entry + 1) ) + sum(all TLV lengths)
        >> 
        >> So, while I see that you want to check that Last Entry doesn't point out
        >> beyond the end of the SRH, I don't see how your computation of max_LE 
        >> helps.
        >> 
        >> What have I missed?
        > 
        > PC: How do you propose to check whether Last Entry value exceeds
        > the maximum possible theoretical Last Entry value?
        > The only information you have is the Header Extension Length. Based
        > on this I compute the maximum theoretical Last Entry possible value,
        > and then just compare the values.
        >
        > Maybe I am the one who have missed something. If you have a simpler
        > proposal please let me know.
        
        OK, we agree that the right thing to do is work out the largest possible Last Entry value (max_LE) and compare it to the actual Last Entry value. That is good.
        
        I also agree that all you have in hand is the Header Extension Length (Hdr Ext Len)
        
        I just don't think that you are computing the right value for max_LE using max_LE = (Hdr Ext Len / 2) - 1.
        
        I would agree that max_LE < (Hdr Ext Len / 2) - 1  so that comparing Last Entry with that value provides a check. I just don't think it is a very precise check.
        
        Perhaps my understanding of the actual value of Hdr Ext Len is incorrect, but if I am right, then you could probably get closer to a good number.
       
    PC: Ok. I rechecked it and I believe that we cannot get any better than that.
    [RFC8200]
    Hdr Ext Len         8-bit unsigned integer.  Length of the Routing
                                  header in 8-octet units, not including the
                                  first 8 octets.
    [draft-ietf-6man-segment-routing-header-26]
    o  Last Entry: contains the index (zero based), in the Segment List,
       of the last element of the Segment List.
    
    Let us consider an SRH containing k SIDs and 0 or more TLVs.
    Hdr Ext Len >= k x (16 / 8) = k x 2
    Last Entry = k - 1
    
    Isolating k on one side of each equation:
    k <= Hdr Ext Len / 2
    k = Last Entry + 1
    
    Combining the two equations together:
    Last Entry + 1 <= Hdr Ext Len / 2
    
    Isolating Last Entry on one side of the equation:
    Last Entry <= Hdr Ext Len / 2 - 1
    
    Further note that, if no TLV is present, we have:
    Last Entry = Hdr Ext Len / 2 - 1
    
    PC: If I'm still missing the point let me know!
    
    AF: Very (very) sorry. My bad.
    I entirely missed " Length of the Routing header *in*8-octet*units*, not including the first 8 octets"
    Now I feel stupid.
    
        >> 6.1
        >> 
        >> I agree with this section, but I am concerned that you are updating 
        >> draft-ietf-6man-segment-routing-header by adding normative language to
        >> describe nodes that process the SRH. Does that mean you should use an
        >> "Updates" clause in the document header?
        >>  
        >> After describing CNT-1 and CNt-2 you say...
        >> 
        >>   Furthermore, an SRv6 capable node maintains an aggregate counter
        >>   CNT-3 tracking the IPv6 traffic that was received with a destination
        >>   address matching a local interface address that is not a locally
        >>   instantiated SID and the next-header is SRH with SL>0.
        >> 
        >> That looks like s/maintains/MUST maintain/ unless you have a reference
        >> for the assertion that it does maintain CNT-3.
        >
        > PC: I disagree that this is an update to the SRH. The SRH defines a
        > header and one type of segment processing.
        > Defining a counter is not related to the SRH at all.
         
        Well, perhaps you didn't just say what you meant to say because the text I quoted most clearly says that the counter is counting events related to the SRH.
        
        But to the point: the document says...
           Any SRv6 capable node SHOULD implement the following set of combined
           counters (packets and bytes):
        "Any SRv6 capable node" is clearly in the scope of draft-ietf-6man-segment-routing-header
    
    PC: This document talks of the processing and behaviours of SRv6. And hence the counters are included in this draft.
    
    AF: Last try before I give up on this one (you may be relieved to know).
    Does every device that supports SRv6 have to support this document? I had formed the impression not: that is a simple SRv6 routing node functions fine without this document (even if this document also describes it's behaviour). But, in the quoted text you are adding description of function for all "SRv6 capable nodes" that is not described elsewhere. So either:
    - it is not possible to have an SRv6 capable node prior to this draft
    or
    - you are updating some other document that describes SRv6 capable nodes

PC: I think we can address this by changing "Any SRv6 capable node" by "A node supporting this document ...".
    
    Many thanks for the work,
    Adrian

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 7 Jan 2020 12:00:54 -0800

Dear Authors, WG Chairs, et al.,
I hope I'm not too late with my comments and questions on the document.
Please kindly consider them as WG LC comments:

   - I have a question regarding the following pseudo-code:

  S08.   max_LE = (Hdr Ext Len / 2) - 1
  S09.   If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) {
  S10.      Send an ICMP Parameter Problem to the Source Address,
               Code 0 (Erroneous header field encountered),
               Pointer set to the Segments Left field.
               Interrupt packet processing and discard the packet.
  S11.   }

According to RFC 8200, Hdr Ext Len is the length of the extension header in
8-octet units, not including the first 8 octets. Thus, as I understand,
max_LE is the length in 8-octet units of half of the extension header less
one. On the other hand, Last Entry and Segments Left are indices. Hence my
question, What is being compared in line S09 ( Last Entry > max_LE)? Length
and index? If the goal is to use Hdr Ext Len to calculate the number of
entries in the header, then what assumption is used in S08? Is it that the
entry's length is always and only 128 bits, i.e. 16 octets? I believe that
using such an assumption is too narrowing and limiting to SRH.

   - Another question is to Section 6.3. What value do you see in this
   section? I've noticed that draft-ietf-6man-spring-srv6-oam is in the
   Informational References section. I agree with that for the first sentence
   in the section. But I believe that the second sentence that refers to the
   new O-bit and OAM behaviors defined in  draft-ietf-6man-spring-srv6-oam
   requires it to be moved into the Normative References section. Unless
   you'll decide to remove the section altogether.

Regards,
Greg

On Thu, Dec 5, 2019 at 9:15 AM <[email-masked]> wrote:

> Hello SPRING,
>
>
>
> This email starts a two weeks Working Group Last Call on draft-ietf-spring-srv6-network-programming [1].
>
>
>
> Please read this document if you haven't read the most recent version, and send your comments to the SPRING WG list, no later than December 20.
>
>
>
> You may copy the 6MAN WG for IPv6 related comment, but consider not duplicating emails on the 6MAN mailing list for the comments which are only spring specifics.
>
>
>
> If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point.
>
> This may help avoiding that the thread become specific to this point and that other points get forgotten (or that the thread get converted into parallel independent discussions)
>
>
>
> Thank you,
>
> Bruno
>
>
>
> [1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05
>
>
>
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Fri, 10 Jan 2020 16:51:41 +0000

Hi Greg,

Inline.

Thanks,
Pablo.

From: Greg Mirsky <[email-masked]>
Date: Tuesday, 7 January 2020 at 21:01
To: Bruno Decraene <[email-masked]>
Cc: SPRING WG List <[email-masked]>, "[email-masked]" <[email-masked]>, draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: WGLC - draft-ietf-spring-srv6-network-programming
Resent from: <[email-masked]>
Resent to: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent date: Tuesday, 7 January 2020 at 21:01

Dear Authors, WG Chairs, et al.,
I hope I'm not too late with my comments and questions on the document. Please kindly consider them as WG LC comments:
·         I have a question regarding the following pseudo-code:
  S08.   max_LE = (Hdr Ext Len / 2) - 1
  S09.   If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) {
  S10.      Send an ICMP Parameter Problem to the Source Address,
               Code 0 (Erroneous header field encountered),
               Pointer set to the Segments Left field.
               Interrupt packet processing and discard the packet.
  S11.   }

According to RFC 8200, Hdr Ext Len is the length of the extension header in 8-octet units, not including the first 8 octets. Thus, as I understand, max_LE is the length in 8-octet units of half of the extension header less one. On the other hand, Last Entry and Segments Left are indices. Hence my question, What is being compared in line S09 ( Last Entry > max_LE)? Length and index? If the goal is to use Hdr Ext Len to calculate the number of entries in the header, then what assumption is used in S08? Is it that the entry's length is always and only 128 bits, i.e. 16 octets? I believe that using such an assumption is too narrowing and limiting to SRH.

PC: This has already been discussed with Adrian. Please check this thread: https://mailarchive.ietf.org/arch/msg/spring/IOA_4nlNPacD2v7Jue2dkGeOABk

·         Another question is to Section 6.3. What value do you see in this section? I've noticed that draft-ietf-6man-spring-srv6-oam is in the Informational References section. I agree with that for the first sentence in the section. But I believe that the second sentence that refers to the new O-bit and OAM behaviors defined in  draft-ietf-6man-spring-srv6-oam requires it to be moved into the Normative References section. Unless you'll decide to remove the section altogether.
PC: The O-bit and OAM behaviors described in draft-ietf-6man-spring-srv6-oam are not required to understand or implement the technology described in draft-ietf-spring-srv6-network-programming. However, they are relevant as to provide additional information to the reader. Why would it be a normative reference?

Regards,
Greg

On Thu, Dec 5, 2019 at 9:15 AM <[email-masked]<mailto:[email-masked]>> wrote:

Hello SPRING,

Thank you,

Bruno

Thank you.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 11 Jan 2020 23:01:01 -0400

Hi Pablo,
thank you for your expedient response. Please find my new notes under GIM>>
tag below in-line.

Regards,
Greg

On Fri, Jan 10, 2020 at 1:09 PM Pablo Camarillo (pcamaril) <
[email-masked]> wrote:

> Hi Greg,
>
>
>
> Inline.
>
>
>
> Thanks,
>
> Pablo.
>
>
>
> *From: *Greg Mirsky <[email-masked]>
> *Date: *Tuesday, 7 January 2020 at 21:01
> *To: *Bruno Decraene <[email-masked]>
> *Cc: *SPRING WG List <[email-masked]>, "[email-masked]" <[email-masked]>,
> draft-ietf-spring-srv6-network-programming <
> [email-masked]>
> *Subject: *Re: WGLC - draft-ietf-spring-srv6-network-programming
> *Resent from: *<[email-masked]>
> *Resent to: *<[email-masked]>, <[email-masked]>, <[email-masked]>, <
> [email-masked]>, <[email-masked]>, <
> [email-masked]>
> *Resent date: *Tuesday, 7 January 2020 at 21:01
>
>
>
> According to RFC 8200, Hdr Ext Len is the length of the extension header
> in 8-octet units, not including the first 8 octets. Thus, as I understand,
> PC: This has already been discussed with Adrian. Please check this thread:
> https://mailarchive.ietf.org/arch/msg/spring/IOA_4nlNPacD2v7Jue2dkGeOABk
>
> GIM>> Thank you for the reference. In some aspects, part of my statement
is repeating your answer to Adrain. The only length on an element in SRH
considered is 128 bits, the length of IPv6 address. I think that your
explanation of how you have arrived at th following formula

 will benefit the document.
My question to you and SPRING WG goes beyond this scenario. Considering
presented in Singapore Unified Identifier proposals (
draft-mirsky-6man-unified-id-sr
<https://datatracker.ietf.org/doc/draft-mirsky-6man-unified-id-sr/> and
draft-wmsaxw-6man-usid-id-use
<https://datatracker.ietf.org/doc/draft-gmsm-bess-evpn-bfd/?include_text=1>),
I believe other scenarios of using SRH, with elements of length other than
128 bits should be accommodated, e.g., 32 bits-long elements.

i.

>
>
> ·         Another question is to Section 6.3. What value do you see in
> this section? I've noticed that draft-ietf-6man-spring-srv6-oam is in the
> PC: The O-bit and OAM behaviors described in draft-ietf-6man-spring-srv6-oam
> are not required to understand or implement the technology described in
> draft-ietf-spring-srv6-network-programming. However, they are relevant as
> to provide additional information to the reader. Why would it be a
> normative reference?
>
GIM>> Ali and I are discussing several aspects of
draft-ietf-6man-spring-srv6-oam. For example, the O-bit is applicable to
any OAM operation or to some part of them. Note that OAM apparatus usually
considered to include Fault Management and Performance Monitoring
protocols. Both may operate as proactive or on-demand. Is the O-bit
applicable to all OAM methods? Then, Fault Management OAM supports
Continuity Check, Connectivity Verification and, for some networks,
Automatic Protection Coordination. How O-bit is used in these methods? Now,
to the Performance Monitoring OAM. I think that the O-bit can be only used
in dual-ended one-way PM OAM. How O-bit may be used in single-ended two-way
PM OAM? Can the O-bit support the Loss Measurement? As you may see, there
are many questions to discuss and clarify in the document. I can imagine
that the result of our work on draft-ietf-6man-spring-srv6-oam may be
somewhat different from its current form. How to ensure synchronization
between SRv6 programming and OAM specifications?

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Mon, 13 Jan 2020 17:31:35 +0000

Hi Greg,

Inline.

Thank you,
Pablo.

From: Greg Mirsky <[email-masked]>
Date: Sunday, 12 January 2020 at 04:01
To: “Pablo Camarillo (pcamaril)” <[email-masked]>
Cc: “[email-masked]” <[email-masked]>
Subject: Re: WGLC – draft-ietf-spring-srv6-network-programming

Hi Pablo,
thank you for your expedient response. Please find my new notes under GIM>> tag below in-line.

Regards,
Greg

On Fri, Jan 10, 2020 at 1:09 PM Pablo Camarillo (pcamaril) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Inline.

Thanks,
Pablo.

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 7 January 2020 at 21:01
To: Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG List <[email-masked]<mailto:[email-masked]>>, “[email-masked]<mailto:[email-masked]>” <[email-masked]<mailto:[email-masked]>>, draft-ietf-spring-srv6-network-programming <[email-masked]<mailto:[email-masked]>>
Subject: Re: WGLC – draft-ietf-spring-srv6-network-programming
Resent from: <[email-masked]<mailto:[email-masked]>>
Resent to: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent date: Tuesday, 7 January 2020 at 21:01

Dear Authors, WG Chairs, et al.,
I hope I’m not too late with my comments and questions on the document. Please kindly consider them as WG LC comments:
•         I have a question regarding the following pseudo-code:
  S08.   Max_LE = (Hdr Ext Len / 2) – 1
  S09.   If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) {
  S10.      Send an ICMP Parameter Problem to the Source Address,
               Code 0 (Erroneous header field encountered),
               Pointer set to the Segments Left field.
               Interrupt packet processing and discard the packet.
  S11.   }

According to RFC 8200, Hdr Ext Len is the length of the extension header in 8-octet units, not including the first 8 octets. Thus, as I understand, max_LE is the length in 8-octet units of half of the extension header less one. On the other hand, Last Entry and Segments Left are indices. Hence my question, What is being compared in line S09 ( Last Entry > max_LE)? Length and index? If the goal is to use Hdr Ext Len to calculate the number of entries in the header, then what assumption is used in S08? Is it that the entry’s length is always and only 128 bits, i.e. 16 octets? I believe that using such an assumption is too narrowing and limiting to SRH.

PC: This has already been discussed with Adrian. Please check this thread: https://mailarchive.ietf.org/arch/msg/spring/IOA_4nlNPacD2v7Jue2dkGeOABk
GIM>> Thank you for the reference. In some aspects, part of my statement is repeating your answer to Adrain. The only length on an element in SRH considered is 128 bits, the length of IPv6 address. I think that your explanation of how you have arrived at th following formula
    S08.   Max_LE = (Hdr Ext Len / 2) – 1
 will benefit the document.
My question to you and SPRING WG goes beyond this scenario. Considering presented in Singapore Unified Identifier proposals (draft-mirsky-6man-unified-id-sr<https://datatracker.ietf.org/doc/draft-mirsky-6man-unified-id-sr/> and draft-wmsaxw-6man-usid-id-use<https://datatracker.ietf.org/doc/draft-gmsm-bess-evpn-bfd/?include_text=1>), I believe other scenarios of using SRH, with elements of length other than 128 bits should be accommodated, e.g., 32 bits-long elements.
i.

PC: It is up to the draft-mirsky authors to standardize in their draft the changes to the SRH processing. As per today the draft-mirsky proposal is still an individual document.

•         Another question is to Section 6.3. What value do you see in this section? I've noticed that draft-ietf-6man-spring-srv6-oam is in the Informational References section. I agree with that for the first sentence in the section. But I believe that the second sentence that refers to the new O-bit and OAM behaviors defined in  draft-ietf-6man-spring-srv6-oam requires it to be moved into the Normative References section. Unless you'll decide to remove the section altogether.
PC: The O-bit and OAM behaviors described in draft-ietf-6man-spring-srv6-oam are not required to understand or implement the technology described in draft-ietf-spring-srv6-network-programming. However, they are relevant as to provide additional information to the reader. Why would it be a normative reference?
GIM>> Ali and I are discussing several aspects of draft-ietf-6man-spring-srv6-oam. For example, the O-bit is applicable to any OAM operation or to some part of them. Note that OAM apparatus usually considered to include Fault Management and Performance Monitoring protocols. Both may operate as proactive or on-demand. Is the O-bit applicable to all OAM methods? Then, Fault Management OAM supports Continuity Check, Connectivity Verification and, for some networks, Automatic Protection Coordination. How O-bit is used in these methods? Now, to the Performance Monitoring OAM. I think that the O-bit can be only used in dual-ended one-way PM OAM. How O-bit may be used in single-ended two-way PM OAM? Can the O-bit support the Loss Measurement? As you may see, there are many questions to discuss and clarify in the document. I can imagine that the result of our work on draft-ietf-6man-spring-srv6-oam may be somewhat different from its current form. How to ensure synchronization between SRv6 programming and OAM specifications?

PC: The current reference in draft-ietf-spring-srv6-network-programming does not explain particular mechanisms of draft-ietf-6man-spring-srv6-oam. It only says that draft-ietf-6man-spring-srv6-oam defines OAM mechanisms for SRv6 as well as the O-bit. This is flexible enough as to be correct regardless of the changes that you make during the WGLC to draft-ietf-6man-spring-srv6-oam.

Regards,
Greg

Hello SPRING,

Thank you,

Bruno

Thank you.

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 19 Jan 2020 11:28:22 -0800

Hi Pablo,
thank you for sharing your opinion. I understand that you believe that
draft-ietf-6man-spring-srv6-oam will not change and will be published with
defining the O-flag as
      O-flag: OAM flag.  When set, it indicates that this packet is an
      operations and management (OAM) packet.
I, on the other hand, am much less certain that that draft and SRv6 OAM, in
general, require the special flag in SRH. I believe that progressing
the draft-ietf-spring-srv6-network-programming with the current text and
the informative reference increases the likelihood that an Errata must be
filed one the SRv6 OAM draft is published.
And as we're discussing a sub-section in the Operation section, I've got
few questions on counters, hope you don't mind:

   - As this is part of the operational considerations, should there be any
   recommendation on the length of the counters?
   - Also, the usual drawback of detailed statistics to characterize a flow
   is scaling. Any consideration and recommendation on that?
   - And last. I didn't find any of these counters being discussed
   in draft-ietf-6man-spring-srv6-oam. Perhaps you can help me with a
   reference to the SRv6 document that uses them.

Regards,
Greg

On Mon, Jan 13, 2020 at 10:23 AM Pablo Camarillo (pcamaril) <
[email-masked]> wrote:

> *Date: *Sunday, 12 January 2020 at 04:01
> *To: *“Pablo Camarillo (pcamaril)” <[email-masked]>
> *Cc: *“[email-masked]” <[email-masked]>
> *Subject: *Re: WGLC – draft-ietf-spring-srv6-network-programming
>
>
>
> Hi Pablo,
>
> *Cc: *SPRING WG List <[email-masked]>, “[email-masked]” <[email-masked]>,
> *Subject: *Re: WGLC – draft-ietf-spring-srv6-network-programming
> I hope I’m not too late with my comments and questions on the document.
> entry’s length is always and only 128 bits, i.e. 16 octets? I believe that
> PC: It is up to the draft-mirsky authors to standardize in their draft the
> changes to the SRH processing. As per today the draft-mirsky proposal is
> still an individual document.
>
>
>
> PC: The O-bit and OAM behaviors described in
> draft-ietf-6man-spring-srv6-oam are not required to understand or implement
> the technology described in draft-ietf-spring-srv6-network-programming.
> However, they are relevant as to provide additional information to the
> reader. Why would it be a normative reference?
>
> PC: The current reference in draft-ietf-spring-srv6-network-programming
> does not explain particular mechanisms of draft-ietf-6man-spring-srv6-oam.
> It only says that draft-ietf-6man-spring-srv6-oam defines OAM mechanisms
> for SRv6 as well as the O-bit. This is flexible enough as to be correct
> regardless of the changes that you make during the WGLC to
> draft-ietf-6man-spring-srv6-oam.
>
>
>
> Regards,
>
> Greg
>
>
>

---

From: Ron Bonica <[email-masked]>
Date: Tue, 21 Jan 2020 15:18:45 +0000

Greg,

I also have reservations about putting the OAM-flag in the routing header for the following reasons:

  *   It has to be examined, even when Segments Left is equal to 0
  *   It is lost with PSP
  *   It has little to do with routing

                                                                            Ron

From: spring <[email-masked]> On Behalf Of Greg Mirsky
Sent: Sunday, January 19, 2020 2:28 PM
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Hi Pablo,
thank you for sharing your opinion. I understand that you believe that draft-ietf-6man-spring-srv6-oam will not change and will be published with defining the O-flag as
      O-flag: OAM flag.  When set, it indicates that this packet is an
      operations and management (OAM) packet.
I, on the other hand, am much less certain that that draft and SRv6 OAM, in general, require the special flag in SRH. I believe that progressing the draft-ietf-spring-srv6-network-programming with the current text and the informative reference increases the likelihood that an Errata must be filed one the SRv6 OAM draft is published.
And as we're discussing a sub-section in the Operation section, I've got few questions on counters, hope you don't mind:

  *   As this is part of the operational considerations, should there be any recommendation on the length of the counters?
  *   Also, the usual drawback of detailed statistics to characterize a flow is scaling. Any consideration and recommendation on that?
  *   And last. I didn't find any of these counters being discussed in draft-ietf-6man-spring-srv6-oam. Perhaps you can help me with a reference to the SRv6 document that uses them..
Regards,
Greg

On Mon, Jan 13, 2020 at 10:23 AM Pablo Camarillo (pcamaril) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Inline.

Thank you,
Pablo.

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Sunday, 12 January 2020 at 04:01
To: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: WGLC - draft-ietf-spring-srv6-network-programming

Hi Pablo,

Regards,
Greg

Inline.

Thanks,
Pablo.

Cc: SPRING WG List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, draft-ietf-spring-srv6-network-programming <[email-masked]<mailto:[email-masked]>>

Dear Authors, WG Chairs, et al.,
I hope I'm not too late with my comments and questions on the document. Please kindly consider them as WG LC comments:
*         I have a question regarding the following pseudo-code:
  S08.   Max_LE = (Hdr Ext Len / 2) - 1
  S09.   If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) {
  S10.      Send an ICMP Parameter Problem to the Source Address,
               Code 0 (Erroneous header field encountered),
               Pointer set to the Segments Left field.
               Interrupt packet processing and discard the packet.
  S11.   }

PC: This has already been discussed with Adrian. Please check this thread: https://mailarchive.ietf.org/arch/msg/spring/IOA_4nlNPacD2v7Jue2dkGeOABk<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/IOA_4nlNPacD2v7Jue2dkGeOABk__;!!NEt6yMaO-gk!VMHP41W_vykFUzLLHFtba1B3jRPYZlG6mWgT4Md1iv5JpsOJ7DGNx3CwPrclGsIY$>
GIM>> Thank you for the reference. In some aspects, part of my statement is repeating your answer to Adrain. The only length on an element in SRH considered is 128 bits, the length of IPv6 address. I think that your explanation of how you have arrived at th following formula
    S08.   Max_LE = (Hdr Ext Len / 2) - 1
 will benefit the document.
My question to you and SPRING WG goes beyond this scenario. Considering presented in Singapore Unified Identifier proposals (draft-mirsky-6man-unified-id-sr<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-mirsky-6man-unified-id-sr/__;!!NEt6yMaO-gk!VMHP41W_vykFUzLLHFtba1B3jRPYZlG6mWgT4Md1iv5JpsOJ7DGNx3CwPmazF_FF$> and draft-wmsaxw-6man-usid-id-use<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-gmsm-bess-evpn-bfd/?include_text=1__;!!NEt6yMaO-gk!VMHP41W_vykFUzLLHFtba1B3jRPYZlG6mWgT4Md1iv5JpsOJ7DGNx3CwPlQOfPGd$>), I believe other scenarios of using SRH, with elements of length other than 128 bits should be accommodated, e.g., 32 bits-long elements.
i.

*         Another question is to Section 6.3. What value do you see in this section? I've noticed that draft-ietf-6man-spring-srv6-oam is in the Informational References section. I agree with that for the first sentence in the section. But I believe that the second sentence that refers to the new O-bit and OAM behaviors defined in  draft-ietf-6man-spring-srv6-oam requires it to be moved into the Normative References section. Unless you'll decide to remove the section altogether.
PC: The O-bit and OAM behaviors described in draft-ietf-6man-spring-srv6-oam are not required to understand or implement the technology described in draft-ietf-spring-srv6-network-programming. However, they are relevant as to provide additional information to the reader. Why would it be a normative reference?
GIM>> Ali and I are discussing several aspects of draft-ietf-6man-spring-srv6-oam. For example, the O-bit is applicable to any OAM operation or to some part of them. Note that OAM apparatus usually considered to include Fault Management and Performance Monitoring protocols. Both may operate as proactive or on-demand. Is the O-bit applicable to all OAM methods? Then, Fault Management OAM supports Continuity Check, Connectivity Verification and, for some networks, Automatic Protection Coordination. How O-bit is used in these methods? Now, to the Performance Monitoring OAM. I think that the O-bit can be only used in dual-ended one-way PM OAM. How O-bit may be used in single-ended two-way PM OAM? Can the O-bit support the Loss Measurement? As you may see, there are many questions to discuss and clarify in the document. I can imagine that the result of our work on draft-ietf-6man-spring-srv6-oam may be somewhat different from its current form. How to ensure synchronization between SRv6 programming and OAM specifications?

Regards,
Greg

Hello SPRING,

Thank you,

Bruno

[1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05__;!!NEt6yMaO-gk!VMHP41W_vykFUzLLHFtba1B3jRPYZlG6mWgT4Md1iv5JpsOJ7DGNx3CwPgy6NSUA$>

Thank you.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!VMHP41W_vykFUzLLHFtba1B3jRPYZlG6mWgT4Md1iv5JpsOJ7DGNx3CwPp1Ddynn$>
--------------------------------------------------------------------

Juniper Business Use Only

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 22 Jan 2020 06:54:11 +0000

Hi Greg,

Inline.

Thanks,
Pablo.

Date: Sunday, 19 January 2020 at 20:28

Hi Pablo,

PC:
I believe that we can trim the text in section 6.3 to avoid mentioning the O-bit without reducing the overall quality of the document.
<old>
   [I-D.ietf-6man-spring-srv6-oam] defines OAM behaviors for SRv6.  This
   includes the definition of the SRH Flag 'O-bit', as well as
   additional SR Endpoint behaviors for OAM purposes.
</old>
<new>
   [I-D.ietf-6man-spring-srv6-oam] defines OAM behaviors for SRv6.  This
   includes the definition of additional SR Endpoint behaviors for OAM purposes.
</new>
Do you agree with this change?

And as we're discussing a sub-section in the Operation section, I've got few questions on counters, hope you don't mind:
·         As this is part of the operational considerations, should there be any recommendation on the length of the counters?
PC: Counter length is implementation dependent. The capabilities of different platforms have significant hairpin as to make any recommendation irrelevant.
·         Also, the usual drawback of detailed statistics to characterize a flow is scaling. Any consideration and recommendation on that?
PC: There is no per-flow statistics. It is a counter per SRv6 SID. An SRv6 SID is shared among different flows. No per-flow scaling is required.
·         And last. I didn't find any of these counters being discussed in draft-ietf-6man-spring-srv6-oam. Perhaps you can help me with a reference to the SRv6 document that uses them.
PC: The counters are required by the controller. Its usage is out of the scope of this document.
Regards,
Greg

Inline.

Thank you,
Pablo.

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Sunday, 12 January 2020 at 04:01
To: “Pablo Camarillo (pcamaril)” <[email-masked]<mailto:[email-masked]>>
Cc: “[email-masked]<mailto:[email-masked]>” <[email-masked]<mailto:[email-masked]>>
Subject: Re: WGLC – draft-ietf-spring-srv6-network-programming

Hi Pablo,

Regards,
Greg

Inline.

Thanks,
Pablo.

Regards,
Greg

Hello SPRING,

Thank you,

Bruno

Thank you.

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 26 Jan 2020 21:35:30 -0800

Hi Pablo,
thank you for your thoughtful consideration of my comments. Please find my
new notes in-line below tagged GIM>>.

Regards,
Greg

On Tue, Jan 21, 2020 at 11:08 PM Pablo Camarillo (pcamaril) <
[email-masked]> wrote:

> *Date: *Sunday, 19 January 2020 at 20:28
> *To: *"Pablo Camarillo (pcamaril)" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> I, on the other hand, am much less certain that that draft and SRv6 OAM,
> in general, require the special flag in SRH. I believe that progressing
> I believe that we can trim the text in section 6.3 to avoid mentioning the
> O-bit without reducing the overall quality of the document.
>
> <old>
>
GIM>> I agree that the new text is more clear and less dependent on the
discussion of I-D.ietf-6man-spring-srv6-oam. Though the "OAM behaviors for
SRv6" that are introduced in the draft, i.e., "punt the packet" and "punt
the packet with a timestamp", are being discussed and may change as the
result of the discussion by 6man WG. Hence I think that it be better to not
to reference   I-D.ietf-6man-spring-srv6-oam altogether.

> ·         As this is part of the operational considerations, should there
> be any recommendation on the length of the counters?
>
> PC: Counter length is implementation dependent. The capabilities of
> different platforms have significant hairpin as to make any recommendation
> irrelevant.
>
> ·         Also, the usual drawback of detailed statistics to characterize
> a flow is scaling. Any consideration and recommendation on that?
>
> PC: There is no per-flow statistics. It is a counter per SRv6 SID. An SRv6
> SID is shared among different flows. No per-flow scaling is required.
>
> ·         And last. I didn't find any of these counters being discussed
GIM>> I think that if SRv6 OAM was part of the network programming draft,
then defining these counters, that are, in my understanding, an integral
part of SRv6 OAM, logical, in the right place. But since SRv6 OAM is
discussed in the draft of its own, I suggest considering moving Section 6.1
Counters to I-D.ietf-6man-spring-srv6-oam.

Regards,