Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

[Greg Mirsky <[e-mail]>]

Hi Daren,
thank you for responding to my question. Is 64-bits routable prefix in the
DA an implicit prerequisite of the C-SID solution?

As to my question about what Brian referred to as a "funny" part. In
Section 6 we read:
   The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths.  A
   C-SID length of 16-bit is recommended.
and then:
   The recommended SRv6 SID block sizes for the NEXT-C-SID flavor are
   16, 32 or 48 bits.

Now, it seems to me that there are many possibilities of getting the
"funny" part of C-SID into a routable space of the DA. For example, an
operator, following the recommendation of the C-SID specification, uses
16-bit NEXT-C-SID in combination with, for example, 32 bits block size. As
a result, 16 bits of "funny" part, i.e., another NEXT-C-SID, are in the
routable space.
Am I missing something? Thank you for your consideration.

Regards,
Greg

On Thu, Oct 21, 2021 at 10:06 PM Darren Dukes (ddukes) <[e-mail]>
wrote:

> Hi Gyan and Greg.
>
> Gyan I’m sorry but i don’t see a question in your email. I’ll go back to
> Greg.
>
> While I’m not exactly sure what is being asked, I will say that Brian is
> correct for every Srv6 SID behavior (not just csid flavors) when he says
> the following about their arguments (lowest 64 bits in the ipv6 Dest addr.
>
> “They are invisible to routing (which is done based on the prefix) and
> invisible to neighbor discovery (because it never happens).”
>
> I hope this helps.
>
> Darren
>
> ------------------------------
> *From:* Gyan Mishra <[e-mail]>
> *Sent:* Thursday, October 21, 2021 7:03 PM
> *To:* Darren Dukes (ddukes)
> *Cc:* Brian E Carpenter; Greg Mirsky; [e-mail]; [e-mail]
> *Subject:* Re: Typo correction Re: Question from SPRING regarding
> draft-filsfilscheng-spring-srv6-srh-compression
>
>
>
> Hi Darren
>
> What Greg is asking is if the SID is a prefix SID End and not adjacency
> SID End.x, so now the common prefix is needed to ECMP steer the flow  to
> the prefix SID which uses the common prefix,  which may in this case be
> mutated due to shifting of SIDs in GSID container.
>
>
> Kind Regards
>
> Gyan
> On Thu, Oct 21, 2021 at 10:18 AM Darren Dukes (ddukes) <ddukes=
> [e-mail]> wrote:
>
>> Hi Greg,
>>
>>
>>
>> Your question is not clear to me.
>>
>> Can you try to restate it with the flavors and behaviors from the draft
>> in question?
>>
>>
>>
>> Darren
>>
>>
>>
>> On 2021-10-20, 4:15 PM, "ipv6" <[e-mail]> wrote:
>>
>>
>>
>> Hi Brian,
>>
>> I've got some questions about what you've said:
>>
>> For that reason, the fact that the bottom 64 bits in the
>>
>> "address" look funny or change is simply irrelevant. They are
>>
>> invisible to routing (which is done based on the prefix)
>>
>> and invisible to neighbor discovery (because it never happens).
>>
>> As I understand it, what you describe is the case of a strict explicit
>> path defined using one of the C-SID compression methods. But I am not sure
>> that your conclusion also always applies when it is a loose explicit path
>> specified in the compressed Segment List. As all C-SIDs share the same
>> prefix, how routing can be done based only on that prefix and not using a
>> part of that "funny" bottom 64 bits? And if any part of the bottom 64 bits
>> must be used, how one can guarantee that CIDR still works in that domain?
>>
>>
>>
>> Regards,
>>
>> Greg
>>
>>
>>
>> On Mon, Oct 18, 2021 at 9:50 PM Brian E Carpenter <
>> [e-mail]> wrote:
>>
>> Hi,
>>
>> After reading a lot of messages, I'm going to offer my considered
>> opinion as a direct response to Joel's OP.
>>
>> Firstly, I don't believe that in the end this draft raises any
>> concerns that are *significantly* different than those raised
>> when RFC 8986 was in draft. As Ted Hardie mentioned, section 5
>> of RFC 8754 explains that SIDs of any shape or size are only
>> meaningful within an SR domain. That applies to srh-compression
>> too.
>>
>> Secondly, I was concerned about how these strange looking
>> "addresses" would potentially interfere with normal IPv6
>> addresses and their handling by normal IPv6 nodes. Well, I
>> now believe that they won't. The reason is that in the SR model
>> these "addresses" are *never used for final delivery of IPv6
>> packets to a host.* All SRv6 participants are routers. The
>> last hop for a packet whose DA is set to (say) 2001:db8:a:1900::
>> is *not* the last hop on a LAN, mediated by neighbor discovery
>> for 2001:db8:a:1900::. It's just a hop from one router to another,
>> using the entry for 2001:db8:a:1900::/64 in the FIB of the last
>> router that actually forwards the packet. 2001:db8:a:1900:: is
>> not assigned to a physical interface so RFC 4861 is never invoked.
>>
>> Another way to say it is RFC 7608 is the relevant architectural
>> standard. CIDR rules, even within an SR domain.
>>
>> For that reason, the fact that the bottom 64 bits in the
>> "address" look funny or change is simply irrelevant. They are
>> invisible to routing (which is done based on the prefix)
>> and invisible to neighbor discovery (because it never happens).
>>
>> I apologise if this is all obvious to everybody, but I needed
>> to spell it out for my own understanding.
>>
>> Now back to Joel's questions:
>>
>>
>> On 13-Oct-21 20:37, Joel M. Halpern wrote:
>> > There is a typo in the below which if not understood as a typo would be
>>
>> > quite confusing.   I wrote that I raised the issue with
>> > "with the Internet ADs and SPRING chairs".
>> > That should have read "with the Internet ADs and 6man chairs".
>> > The SPRING co-chairs are recused, and the charter requirement leads to
>> > the 6man chairs.  Which is who I talked to.
>> >
>> > Also, I am sending a courtesy copy to the routing ADs, which I should
>> > have done originally.
>> >
>> > Thank you and enjoy.
>> > Yours,
>> > Joel
>> >
>> > On 10/12/2021 11:52 PM, Joel M. Halpern wrote:
>> >> The SPRING working group is in the midst of an adoption call on
>> >>
>> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/.
>>
>> >>
>> >>
>> >> The SPRING charter has text that is explicit that modifications to
>> data
>> >> planes and architectures standardized by other working groups may not
>> be
>> >> modified in SPRING unless the chairs and ADs responsible for that data
>>
>> >> plane and / or architecture agree.
>> >>
>> >> To complete the context, as my SPRING co-chairs are co-authors on the
>> >> document in question, they have recused themselves from decisional
>> >> activities regarding the document.  Therefore, this message is coming
>> >> just from my as the responsible SPRING co-chair managing this adoption
>>
>> >> call.
>> >>
>> >> As you have seen, multiple questions have been raised about the
>> >> relationship of the document to the IPv6 defined data plane and
>> >> architecture (particularly RFC 4291 and 8200). In particular the
>> >> questions seem to revolve around what the document describes as the
>> >> NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6
>> >> standards.  (For those seeking more context without reading the full
>> >> document, a paraphrase and simplification of the NEXT-C_SID flavor is
>> >> provided as a postscript.)
>> >>
>> >> I raised the question of concurrence as required by the SPRING charter
>>
>> >> with the Internet ADs and SPRING chairs.  They quite reasonably asked
>> me
>> >> to write a note to 6man explaining the concerns as clearly as a can,
>> so
>> >> that they can then determine how to proceed.
>> >>
>> >> The questions that prompted my inquiry are:
>> >>
>> >> 1) Does the placement of a list of sids in the IPv6 DA field change
>> the
>> >> IPv6 architectural description of that field.
>>
>> I think it should be noted explicitly somewhere that since the contents
>> of the DA field are *never* used for last-hop neighbor discovery,
>> the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942
>> are irrelevant. Another citation is RFC 7608: for routing, all that
>> counts is the prefix, and it can be anything up to 128.
>>
>> Perhaps this should have been in section 5 of RFC 8754, but I leave
>> that to the wordsmiths.
>>
>> >> 2) Does the operation of shifting information around in the IPv6
>> >> destination address field represent a modification or extension of the
>>
>> >> IPv6 data plane.
>>
>> No. As my text above indicates, the SRv6 DA field is only ever used
>> by routing, where RFC 7608 rules. And of course it vanishes as soon
>> as the packet is decapsulated.
>>
>> Regards
>>     Brian
>>
>> >>
>> >> On a related note, the document in question also defines two other
>> >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.  The
>> >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID
>> >> flavor operation, so seems to be affected by the same question.
>> >>
>> >>  From my own reading, it appears that the REPLACE-C-SID flavor does
>> not
>> >> raise issues requiring 6man leadership concurrence.
>> >>
>> >> Yours,
>> >> Joel M. Halpern for the SPRING working group
>> >>
>> >>
>> >> PS:
>> >> Clearly, understanding the question requires some understanding of
>> what
>> >> the NEXT-C_SID flavor does.   This explanation is a simplification for
>> >> length and context.  Really, the best place to understand it is the
>> >> draft.  However, to give you enough information to let you decide
>>
>> >> whether you care, I will try to provide a fair summary.  My apologies
>> in
>> >> advance to the authors for necessary liberties for length.  Also,
>>
>> >> discussion of the draft contents (as distinct from the interaction
>> with
>> >> the IPv6 data plane and architecture) belongs on the SPRING list, and
>> >> should not clutter up 6man.
>> >>
>> >> SIDs are the identifiers used in segment routing.
>> >> In SRv6, as document in the current RFCs, these are 128 bits.   As
>> >> defined in the relevant RFCs, SIDs which identify endpoints to which
>> >> packets are directed are identified by endpoint SIDs.  These can have
>> >> behaviors (decapsulate and forward is one example).  They can have
>> >> flavors such as where the SRH is removed.
>> >>
>> >> The topic under discussion is means to compress these SIDs in the
>> >> packets on the wire.  The document under discussion provides three
>> >> flavors of compression.
>> >>
>> >> The fundamental mechanism of the draft is to use a single SRH entry as
>> a
>> >> container for multiple SIDs.  In the NEXT-C_SID mechanism, when it is
>> >> first encountered the entire container is copied into the desination
>> >> address of the IPv6 packet.  The container has a common routing prefix
>> >> used for all the NEXT-C-SID SIDs.  It is followed by a sequence of
>> >> compressed SIDs of a configured length.  One could configure 16, 24,
>> or
>> >> 32 bits.  Or whatever length.  The routing advertisements are arranged
>> >> so that the IPv6 packet is directed to the node represented by the
>> first
>> >> compressed SID on the basis of longest prefix match matching the
>> >> combination of the common routing prefix and that compressed SID.
>> >>
>> >> When the packet arrives at that node, it looks up the configured
>> >> portion, the compressed SID, and determines the behavior and flavor.
>> In
>> >> the case of the NEXT-C-SID flavor, the resulting operation is to shift
>>
>> >> the entire remaining contents of the IPv6 address (the bits past the
>> >> first compressed sid) so as to over-write the first compressed SID.  0
>> >> bits are shifted into the low order positions.  If the result is a
>> >> non-zero new first compressed SID, then the packets is forwarded and
>> the
>> >> process repeats.  When all that is left are 0s, if there is an SRH, it
>> >> is consulted to find the next SRH entry, which is, per normal SRv6
>> >> processing, put into the IPv6 DA.
>> >> Note that in the common case where the SIDS needed all fit in to a
>> >> single container, the analysis also assumes the use of the reduced
>> >> encapsulation options which omits the SRH that is not needed as it
>> would
>> >> have no entries.  This the packet contains a normal IPv6 header, with
>> a
>> >> sequence of compressed SIDs (what one might or might not call a source
>>
>> >> route) in the IPv6 destination address field.
>> >>
>> >> PPS: If the authors of the NEXT-C-SID flavor feel I have
>> mis-represented
>> >> the work, please, send clarifications or corrections.   Again, the
>> best
>> >> source of information is the draft itself.  I was asked to provide
>> extra
>> >> context in this email.
>> >
>> > --------------------------------------------------------------------
>> > IETF IPv6 working group mailing list
>> > [e-mail]
>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > --------------------------------------------------------------------
>> >
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [e-mail] <[e-mail]>*
>
>
>
> *M 301 502-1347 *
>
>