Makes sense. Thank you
Gyan Sent from my iPhone > On Apr 19, 2019, at 3:30 AM, Robert Raszuk <[email protected]> wrote: > > > And what happens - > > When there is an SRH and Segments Left is not equal to 0 ? > > >> On Fri, Apr 19, 2019 at 4:53 AM Ron Bonica <[email protected]> wrote: >> Hi Jim, >> >> >> >> Thanks for asking this insightful question. The answer depends on the SID >> type. >> >> >> >> Some service SIDs (e.g., END.DX4, END.DX6, END.DT4, END.DT6) are processed >> only in the following conditions: >> >> >> >> When there is no SRH >> When there is an SRH and Segments Left is equal to 0 >> >> >> Such SIDs should be encoded in the Destination Options header that >> immediately precedes the upper-layer header. This is because the Destination >> Options header that immediately precedes the upper-layer header is only >> processed when: >> >> >> >> When there is no SRH >> When there is an SRH and Segments Left is equal to 0 >> >> >> Moreover, Destination options are of variable length. So, each SID can be as >> long or short as it needs to be. One SID type can be long while another is >> short and neither needs to be the same length as SIDs that are encoded in >> the IPv6 Routing header. >> >> >> >> The VPN Context Information Option [draft-bonica-6man-vpn-dest-opt] is an >> example of such an encoding. It serves the same purpose as many of the SID >> defined in draft-filsfils-spring-srv6-network-programming (e.g., END.DX4, >> END..DX6, END.DT4, END.DT6). As more service SIDs of this type are >> identified, more destination options will be defined. >> >> >> >> Other Service SIDs can be processed when an SRH is present and Segments Left >> is greater than zero. Ideally, these SIDs should be encoded in the >> Destination Options Header that immediately precedes the Routing header. >> This is because the Destination Options Header that immediately precedes the >> Routing header is processed by every segment endpoint. >> Draft-bonica-6man-seg-end-opt offers one such encoding scheme, but it is not >> the only one. >> >> >> >> Another possibility is to encode these SIDs the Destination Options header >> that immediately precedes the upper-layer header and required Service >> Function Instances that support these SIDs to look ahead. >> >> >> >> >> >> >> Ron >> >> >> >> >> >> >> >> Juniper Internal >> From: James N Guichard <[email protected]> >> Sent: Thursday, April 18, 2019 5:57 PM >> To: Ron Bonica <[email protected]>; Robert Raszuk <[email protected]> >> Cc: SPRING WG <[email protected]>; [email protected]; Dino Farinacci >> <[email protected]>; [email protected] list <[email protected]>; James N Guichard >> <[email protected]> >> Subject: RE: [spring] IPv6-compressed-routing-header-crh >> >> >> >> Hi Ron, >> >> >> >> I am wondering about how do you plan to handle service SIDs (or any SID with >> embedded functions) at intermediate nodes; draft-bonica-6man-vpn-dest-opt >> seems to only handle the case where the endpoint will process the >> destination option: >> >> >> >> Section 4 says: “It MUST NOT appear in a Hop-by-hop Options header and >> SHOULD NOT appear in a Destination Options header that precedes a Routing >> header”. >> >> >> >> If you relax the latter and encode the SID in a destination option preceding >> the CRH (or SRH) then wouldn’t every node in the segment-list have to >> process the SID and figure out whether it is a local SID or not? That would >> seem to be overly complex given you could just encode the SID in the CRH (or >> SRH) and only the node where said SID is exposed would process it. >> >> >> >> Thanks! >> >> >> >> Jim >> >> >> >> From: ipv6 [mailto:[email protected]] On Behalf Of Ron Bonica >> Sent: Thursday, April 18, 2019 4:30 PM >> To: Robert Raszuk <[email protected]> >> Cc: SPRING WG <[email protected]>; [email protected]; Dino Farinacci >> <[email protected]>; [email protected] list <[email protected]> >> Subject: RE: [spring] IPv6-compressed-routing-header-crh >> >> >> >> Robert, >> >> >> >> The Compressed Routing Header (CRH) has exactly one function. That is to >> route a packet for segment to segment along an SR path. Therefore, SIDs >> contained by the CRH have only one function. That is to steer packets to the >> next segment. >> >> >> >> Granted, we may want to program a service behavior at a segment endpoint. >> IPv6 includes a Destination Options header that can be used to convey >> information segment endpoints and destination options can contain service >> SIDs. These service SIDs can be as long or short as they need to be. See >> draft-bonica-6man-vpn-dest-opt for an example. >> >> >> >> >> Ron >> >> >> >> >> >> Juniper Internal >> From: Robert Raszuk <[email protected]> >> Sent: Thursday, April 18, 2019 10:30 AM >> To: Ron Bonica <[email protected]> >> Cc: Gyan Mishra <[email protected]>; Tom Herbert <[email protected]>; >> SPRING WG <[email protected]>; [email protected]; Dino Farinacci >> <[email protected]>; [email protected] list <[email protected]> >> Subject: Re: [spring] IPv6-compressed-routing-header-crh >> >> >> >> Hi Ron, >> >> >> >> I must observe that your analysis is incorrect. >> >> >> >> SIDs are not only used for TE or traffic steering purposes but what is even >> more interesting for various functions - for example NFV. >> >> >> >> So you need as much SIDs as possible imagination of your value add network >> functions - which will be different from those functions at the encap dst >> which as you indicate in other draft can be carried in destination options. >> >> >> >> That debate is still I think open. >> >> >> >> Thx, >> >> R. >> >> >> >> >> >> On Thu, Apr 18, 2019 at 4:02 PM Ron Bonica <[email protected]> wrote: >> >> Gyan, >> >> >> >> Let’s think about how a network operator might choose a SID size…. >> >> >> >> Assume that an MAN includes 100 routers. These routers are connected to one >> another by infrastructure links. Each router has 20 or fewer infrastructure >> links. >> >> >> >> The network operator might assign one loosely routes SID to each router. >> These loosely routed SIDs have network-wide significance (i.e., the cannot >> be reused). >> >> >> >> The network operator might also assign one strictly routed SID to each >> link.. The strictly routed SIDs have node-local significance only. They can >> be reused from one node to another. >> >> >> >> So, in this case, the network operator only needs 120 SIDs. This fits in >> eight bits with plenty of room for growth. >> >> >> >> Now consider another network that includes 30,000 routers. Each router is >> connected to its peers by 200 infrastructure links or fewer. This network >> would need 30,200 SIDs. This would fit in 16 bits. >> >> >> >> A *really big* network might require more than 32,000 SIDs. So, we support a >> 32-bit SID... >> >> >> >> >> Ron >> >> >> >> >> >> >> >> >> >> Juniper Internal >> From: Gyan Mishra <[email protected]> >> Sent: Wednesday, April 17, 2019 10:00 PM >> To: Ron Bonica <[email protected]> >> Cc: Robert Raszuk <[email protected]>; Tom Herbert <[email protected]>; >> SPRING WG <[email protected]>; [email protected]; Dino Farinacci >> <[email protected]>; [email protected] list <[email protected]> >> Subject: Re: [spring] IPv6-compressed-routing-header-crh >> >> >> >> >> >> I agree to make the SID align on word boundaries but I am thinking the >> software should have hardware independence if at all possible. >> >> >> >> I think 32 bit is a reasonable size. >> >> >> >> >> >> Gyan S. Mishra >> >> IT Network Engineering & Technology Consultant >> >> Routing & Switching / Service Provider MPLS & IPv6 Expert >> >> www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT >> >> Mobile – 202-734-1000 >> >> >> >> Sent from my iPhone >> >> >> On Apr 14, 2019, at 7:54 PM, Ron Bonica >> <[email protected]> wrote: >> >> Hi Robert, >> >> >> >> In order to make the CRH ASIC-friendly, we have the following constraints: >> >> >> >> Support only a small handful of SID lengths >> If at all possible, make them align on word boundaries >> >> >> Currently, we support 8, 16 and 32 bytes. Do you see a reason why we should >> support a length greater than 32? Is there some length less than 32 that >> would be beneficial? >> >> >> >> Ron >> >> >> >> >> >> >> >> Juniper Internal >> From: spring <[email protected]> On Behalf Of Robert Raszuk >> Sent: Friday, April 12, 2019 6:13 PM >> To: Tom Herbert <[email protected]> >> Cc: SPRING WG <[email protected]>; [email protected]; Mark Smith >> <[email protected]>; Dino Farinacci <[email protected]>; >> [email protected] list <[email protected]> >> Subject: Re: [spring] IPv6-compressed-routing-header-crh >> >> >> >> Hi Tom, >> >> >> >> I already suggested this on March 30th ... >> >> >> >> "PS. But if you choose to go ahead with CRH I would highly advise to make >> your CRH SID a variable length. " >> >> >> >> No feedback/response was received from authors. >> >> >> >> Thx, >> R. >> >> >> >> On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert <[email protected]> wrote: >> >> On Fri, Apr 12, 2019 at 1:48 PM Mark Smith <[email protected]> wrote: >> > >> > Hi Tom, >> > >> > On Sat, 13 Apr 2019 at 00:26, Tom Herbert <[email protected]> wrote: >> > > >> > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk <[email protected]> wrote: >> > > > >> > > > Hi Mark, >> > > > >> > > > > As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary >> > > > > and a 32 bit alignment, >> > > > > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 >> > > > > network. >> > > > > >> > > > > As 32 bit SIDs are also the same size as IPv4 addresses, that may >> > > > > also create some opportunities to >> > > > > leverage IPv4 support in existing protocols to suite carrying and >> > > > > processing 32 bit SIDs with some, possibly >> > > > > slight, modification. For example, perhaps IPv4 Address Family >> > > > > support in OSPFv3 (RFC 5838) could be >> > > > > somehow leveraged to suit SR. >> > > > >> > > > >> > > > Thank you for describing your understanding of fundamentals of SR. >> > > > >> > > > I think SR while indeed started with the story of "less control plane >> > > > is good for you" now clearly has evolved into not only reduction of >> > > > control plane but what can be even more important to some users >> > > > ability to request specific behavior via programmed functions of >> > > > network elements on a per flow basis without actually per flow or per >> > > > path signalling or state. >> > > > >> > > > Yes for some it may be very useful feature and I am sure some will >> > > > call it overload of data plane or . There is no one size fits all. >> > > > >> > > > With that let's observe that till today SR did not require any new >> > > > mapping plane to be distributed in control plane and to be inserted >> > > > into data plane. This is clearly a precedent. >> > > > >> > > > Furthermore as we see in companion documents all additional network >> > > > functionality is being taken away from SRH and is being shifted to >> > > > Destination Options . >> > > > >> > > > As far as mapping plane I already pointed out in my Vector Routing >> > > > proposal that we have one already it is called BGP. One needs to also >> > > > observe that we as industry worked number of years of protocol suite >> > > > called LISP allowing not only very good mapping plane, but also data >> > > > plane integration. CC-ing lisp authors for their comments. Note also >> > > > work for integrating SRv6 with LISP which is already is published. >> > > > >> > > > Since you correctly observed that now SID can be 32 bit and that is >> > > > similar to the size of IPv4 my fundamental question is why not use >> > > > something which already exists instead of defining some sort of new >> > > > from scratch ? >> > > > >> > > Robert, >> > > >> > > I don't see in the SRH draft where 32 bit SIDs are defined. Can you >> > > please provide a reference? >> > > >> > >> > To clarify, I've been thinking about the idea of a smaller SID size >> > for IPv6 for a while now (since inserting EHs came up), and thought >> > about what would be a generic single size that might suit SR that >> > wasn't the same size as an IPv6 address. 32 bits seemed suitable to >> > me, although if people wanted bigger, I'd be suggesting 64 bits (not >> > entirely coincidentally the common IID size.) >> > >> > Ron and others have written this draft, which supports SIDS of various >> > sizes - 8, 16 or 32 bits - that triggered this discussion. >> > >> Mark, >> >> Why not just put a SID length field in the header (like RFC6554 but >> more generic). That would allow lengths of 1-16 bytes. Additional >> flags could be used to indicate the semantics of the entries. For >> instance, they might be actual addresses (128 bits for IPv6, 32 bits >> for IPv4), parts of addresses (prefixes of suffixes like in RFC6554) >> where the rest of the address can be inferred, indices into a table, >> labels, etc. >> >> Tom >> >> > "The IPv6 Compressed Routing Header (CRH)" >> > https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03 >> > >> > Regards, >> > Mark. >> > >> > >> > > As for trying to use something that already exists, why does SR used a >> > > fixed size format for SIDs instead of a variable length format like >> > > that described in RFC6554? Similarly, why does SR define it's own TLV >> > > format instead of using Hop-by-Hop and Destination Options defined in >> > > RFC8200? >> > > >> > > Tom >> > > >> > > > It will be perfectly fine to have full proper SRv6 with SRH and LISP >> > > > or Vector Routing as an alternative options. I really do not see a >> > > > room or need for yet one more mapping plane. What problem does it >> > > > solve which would not be already solved elsewhere ? >> > > > >> > > > Kind regards, >> > > > Robert >> > > > >> > > > >> > > >>> 2) Is there an agreement that solutions which require additional per >> > > >>> SR path state in both control plane and now in data plane are really >> > > >>> something we should be endorsing here ? >> > > >> >> > > >> >> > > >> I think so. >> > > >> >> > > >> My understanding of what SR is fundamentally about is to reduce >> > > >> control plane state and processing. The trade-off for reduced control >> > > >> plane state and processing is to instead carry and encode most or all >> > > >> of that information or its semantics as per-packet overhead. >> > > >> >> > > >> If the per-packet overhead becomes too large and expensive, then >> > > >> pushing some of that information and processing back into the control >> > > >> plane should be ok, as long as there is still a beneficial overall >> > > >> reduction in control plane state and processing. >> > > >> >> > > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary >> > > >> and a 32 bit alignment, I'd think 32 bit SIDs would be adequate to >> > > >> perform SR in an IPv6 network. >> > > >> >> > > >> As 32 bit SIDs are also the same size as IPv4 addresses, that may >> > > >> also create some opportunities to leverage IPv4 support in existing >> > > >> protocols to suite carrying and processing 32 bit SIDs with some, >> > > >> possibly slight, modification. For example, perhaps IPv4 Address >> > > >> Family support in OSPFv3 (RFC 5838) could be somehow leveraged to >> > > >> suit SR. >> > > >> >> > > >> Regards, >> > > >> Mark. >> > > > >> > > > -------------------------------------------------------------------- >> > > > IETF IPv6 working group mailing list >> > > > [email protected] >> > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> > > > -------------------------------------------------------------------- >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> [email protected] >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
