[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: Re: Fwd: New Version Notification for draft-voyer-6man-extension-header-insertion-07.txt
From: Mark Smith <markzzzsmith () gmail ! com>
Date: 2019-09-22 0:58:18
Message-ID: CAO42Z2z9Q1rvDpjuod7+9eBBwH=wHbduGKvp9P4qmSgjW7B7aA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Sun, 22 Sep 2019, 03:02 Voyer, Daniel, <daniel.voyer@bell.ca> wrote:
> Hi Joel,
>
> Sent from my mobile
>
> > On Sep 21, 2019, at 00:54, Joel M. Halpern <jmh@joelhalpern.com> wrote:
> >
> > I see where the draft defines a set of constraints.
> > The constraint that there be no other extension headers is a fairly
> drastic constraint, which would seem a cause for concern.
> >
> > Putting that aside however, the draft does not seem to provide any
> explanation for why insertion rather than additional encapsulation is
> used. Particularly given the assumption that the MTU is large enough, it
> seems the encapsulation could be used for all insertion cases.
> >
> DV: correct, you can use encapsulations but at the cost of 40bytes
> overhead. Running an operators backbone, with a widespread among of use
> cases, you need those bytes..
>
Clear evidence that 128 bit SIDs are the actual problem.
These SIDs can literally encode more values than the entire possible IPv6
unicast address space can. There can literally be more SID values than
there will ever be IPv6 hosts for all time.
That can't be a requirement if SR can operate adequately operate over MPLS
with only 20 bit SIDs. Surely 16 or 32 bit SIDs would be adequate when
operating SR over IPv6.
Give up these massive 128 bit SIDs for a much more functionally appropriate
size and you can use RFC8200 compliant operations without any overhead
concerns.
>
>
> > Yours,
> > Joel
> Regards
> Dan
> >
> >> On 9/21/2019 12:34 AM, Darren Dukes (ddukes) wrote:
> >> Hello everyone, we've just submitted an updated draft that explains why
> SRH insertion is performed in an SR domain, how it is accomplished and why
> it is safe within the SR domain.
> >> The authors look forward to your comments and suggestions on how to
> improve this document.
> >> Thanks!
> >> Darren (on behalf of the authors)
> >>> Begin forwarded message:
> >>>
> >>> *From: *<internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
> >>> *Subject: **New Version Notification for
> draft-voyer-6man-extension-header-insertion-07.txt*
> >>> *Date: *September 21, 2019 at 12:20:13 AM EDT
> >>>
> >>>
> >>> A new version of I-D,
> draft-voyer-6man-extension-header-insertion-07.txt
> >>> has been successfully submitted by Darren Dukes and posted to the
> >>> IETF repository.
> >>>
> >>> Name:draft-voyer-6man-extension-header-insertion
> >>> Revision:07
> >>> Title:Insertion of IPv6 Segment Routing Headers in a Controlled Domain
> >>> Document date:2019-09-20
> >>> Group:Individual Submission
> >>> Pages:13
> >>> URL:
> https://www.ietf.org/internet-drafts/draft-voyer-6man-extension-header-insertion-07.txt
> >>> Status:
> https://datatracker.ietf.org/doc/draft-voyer-6man-extension-header-insertion/
> >>> Htmlized:
> https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-07
> >>> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-voyer-6man-extension-header-insertion
> >>> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-voyer-6man-extension-header-insertion-07
> >>>
> >>> Abstract:
> >>> Traffic traversing an SR domain is encapsulated in an outer IPv6
> >>> header for its journey through the SR domain.
> >>>
> >>> To implement transport services strictly within the SR domain, the SR
> >>> domain may require insertion or removal of an SRH after the outer
> >>> IPv6 header of the SR domain. Any segment within the SRH is strictly
> >>> contained within the SR domain.
> >>>
> >>> The SR domain always preserves the end-to-end integrity of traffic
> >>> traversing it. No extension header is manipulated, inserted or
> >>> removed from an inner transported packet. The packet leaving the SR
> >>> domain is exactly the same (except for the hop-limit update) as the
> >>> packet entering the SR domain.
> >>>
> >>> The SR domain is designed with link MTU sufficiently greater than the
> >>> MTU at the ingress edge of the SR domain.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Please note that it may take a couple of minutes from the time of
> submission
> >>> until the htmlized version and diff are available at tools.ietf.org <
> http://tools.ietf.org>.
> >>>
> >>> The IETF Secretariat
> >>>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
> ------------------------------------------------------------------------------
> > External Email: Please use caution when opening links and attachments /
> Courriel externe: Soyez prudent avec les liens et documents joints
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
[Attachment #5 (text/html)]
<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Sun, 22 Sep 2019, 03:02 Voyer, Daniel, <<a \
href="mailto:daniel.voyer@bell.ca" rel="noreferrer noreferrer noreferrer noreferrer" \
target="_blank">daniel.voyer@bell.ca</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Hi Joel, <br> <br>
Sent from my mobile<br>
<br>
> On Sep 21, 2019, at 00:54, Joel M. Halpern <<a \
href="mailto:jmh@joelhalpern.com" rel="noreferrer noreferrer noreferrer noreferrer \
noreferrer" target="_blank">jmh@joelhalpern.com</a>> wrote:<br> > <br>
> I see where the draft defines a set of constraints.<br>
> The constraint that there be no other extension headers is a fairly drastic \
constraint, which would seem a cause for concern.<br> > <br>
> Putting that aside however, the draft does not seem to provide any explanation \
for why insertion rather than additional encapsulation is used. Particularly given \
the assumption that the MTU is large enough, it seems the encapsulation could be used \
for all insertion cases.<br> > <br>
DV: correct, you can use encapsulations but at the cost of 40bytes overhead.. Running \
an operators backbone, with a widespread among of use cases, you need those \
bytes..<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Clear \
evidence that 128 bit SIDs are the actual problem.</div><div \
dir="auto"><br></div><div dir="auto">These SIDs can literally encode more values than \
the entire possible IPv6 unicast address space can.. There can literally be more SID \
values than there will ever be IPv6 hosts for all time.</div><div \
dir="auto"><br></div><div dir="auto">That can't be a requirement if SR can \
operate adequately operate over MPLS with only 20 bit SIDs. Surely 16 or 32 bit SIDs \
would be adequate when operating SR over IPv6.</div><div dir="auto"><br></div><div \
dir="auto">Give up these massive 128 bit SIDs for a much more functionally \
appropriate size and you can use RFC8200 compliant operations without any overhead \
concerns.</div><div dir="auto"><br></div><div dir="auto"><br></div><div \
dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div \
dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 \
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><br><br>
> Yours,<br>
> Joel<br>
Regards<br>
Dan<br>
> <br>
>> On 9/21/2019 12:34 AM, Darren Dukes (ddukes) wrote:<br>
>> Hello everyone, we've just submitted an updated draft that explains why SRH \
insertion is performed in an SR domain, how it is accomplished and why it is safe \
within the SR domain.<br> >> The authors look forward to your comments and \
suggestions on how to improve this document.<br> >> Thanks!<br>
>> Darren (on behalf of the authors)<br>
>>> Begin forwarded message:<br>
>>> <br>
>>> *From: *<<a href="mailto:internet-drafts@ietf.org" rel="noreferrer \
noreferrer noreferrer noreferrer noreferrer" \
target="_blank">internet-drafts@ietf.org</a> <mailto:<a \
href="mailto:internet-drafts@ietf.org" rel="noreferrer noreferrer noreferrer \
noreferrer noreferrer" target="_blank">internet-drafts@ietf.org</a>>><br> \
>>> *Subject: **New Version Notification for \
draft-voyer-6man-extension-header-insertion-07.txt*<br> >>> *Date: \
*September 21, 2019 at 12:20:13 AM EDT<br> >>> <br>
>>> <br>
>>> A new version of I-D, \
draft-voyer-6man-extension-header-insertion-07.txt<br> >>> has been \
successfully submitted by Darren Dukes and posted to the<br> >>> IETF \
repository.<br> >>> <br>
>>> Name:draft-voyer-6man-extension-header-insertion<br>
>>> Revision:07<br>
>>> Title:Insertion of IPv6 Segment Routing Headers in a Controlled \
Domain<br> >>> Document date:2019-09-20<br>
>>> Group:Individual Submission<br>
>>> Pages:13<br>
>>> URL: <a \
href="https://www.ietf.org/internet-drafts/draft-voyer-6man-extension-header-insertion-07.txt" \
rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" \
target="_blank">https://www.ietf.org/internet-drafts/draft-voyer-6man-extension-header-insertion-07.txt</a><br>
>>> Status: <a \
href="https://datatracker.ietf.org/doc/draft-voyer-6man-extension-header-insertion/" \
rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" \
target="_blank">https://datatracker.ietf.org/doc/draft-voyer-6man-extension-header-insertion/</a><br>
>>> Htmlized: <a \
href="https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-07" \
rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" \
target="_blank">https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-07</a><br>
>>> Htmlized: <a \
href="https://datatracker.ietf.org/doc/html/draft-voyer-6man-extension-header-insertion" \
rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" \
target="_blank">https://datatracker.ietf.org/doc/html/draft-voyer-6man-extension-header-insertion</a><br>
>>> Diff: <a \
href="https://www.ietf.org/rfcdiff?url2=draft-voyer-6man-extension-header-insertion-07" \
rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" \
target="_blank">https://www.ietf.org/rfcdiff?url2=draft-voyer-6man-extension-header-insertion-07</a><br>
>>> <br>
>>> Abstract:<br>
>>> Traffic traversing an SR domain is encapsulated in an outer IPv6<br>
>>> header for its journey through the SR domain.<br>
>>> <br>
>>> To implement transport services strictly within the SR domain, the \
SR<br> >>> domain may require insertion or removal of an SRH after the \
outer<br> >>> IPv6 header of the SR domain. Any segment within the SRH \
is strictly<br> >>> contained within the SR domain.<br>
>>> <br>
>>> The SR domain always preserves the end-to-end integrity of \
traffic<br> >>> traversing it. No extension header is manipulated, \
inserted or<br> >>> removed from an inner transported packet. The \
packet leaving the SR<br> >>> domain is exactly the same (except for the \
hop-limit update) as the<br> >>> packet entering the SR domain.<br>
>>> <br>
>>> The SR domain is designed with link MTU sufficiently greater than \
the<br> >>> MTU at the ingress edge of the SR domain.<br>
>>> <br>
>>> <br>
>>> <br>
>>> <br>
>>> <br>
>>> Please note that it may take a couple of minutes from the time of \
submission<br> >>> until the htmlized version and diff are available at <a \
href="http://tools.ietf.org" rel="noreferrer noreferrer noreferrer noreferrer \
noreferrer noreferrer" target="_blank">tools.ietf.org</a> <<a \
href="http://tools.ietf.org" rel="noreferrer noreferrer noreferrer noreferrer \
noreferrer noreferrer" target="_blank">http://tools.ietf.org</a>>.<br> \
>>> <br> >>> The IETF Secretariat<br>
>>> <br>
>> --------------------------------------------------------------------<br>
>> IETF IPv6 working group mailing list<br>
>> <a href="mailto:ipv6@ietf.org" rel="noreferrer noreferrer noreferrer \
noreferrer noreferrer" target="_blank">ipv6@ietf.org</a><br> >> Administrative \
Requests: <a href="https://www.ietf.org/mailman/listinfo/ipv6" rel="noreferrer \
noreferrer noreferrer noreferrer noreferrer noreferrer" \
target="_blank">https://www.ietf.org/mailman/listinfo/ipv6</a><br> >> \
--------------------------------------------------------------------<br> > <br>
> --------------------------------------------------------------------<br>
> IETF IPv6 working group mailing list<br>
> <a href="mailto:ipv6@ietf.org" rel="noreferrer noreferrer noreferrer noreferrer \
noreferrer" target="_blank">ipv6@ietf.org</a><br> > Administrative Requests: <a \
href="https://www.ietf.org/mailman/listinfo/ipv6" rel="noreferrer noreferrer \
noreferrer noreferrer noreferrer noreferrer" \
target="_blank">https://www.ietf.org/mailman/listinfo/ipv6</a><br> > \
--------------------------------------------------------------------<br> > \
------------------------------------------------------------------------------<br> \
> External Email: Please use caution when opening links and attachments / Courriel \
externe: Soyez prudent avec les liens et documents joints<br>
--------------------------------------------------------------------<br>
IETF IPv6 working group mailing list<br>
<a href="mailto:ipv6@ietf.org" rel="noreferrer noreferrer noreferrer noreferrer \
noreferrer" target="_blank">ipv6@ietf.org</a><br> Administrative Requests: <a \
href="https://www.ietf.org/mailman/listinfo/ipv6" rel="noreferrer noreferrer \
noreferrer noreferrer noreferrer noreferrer" \
target="_blank">https://www.ietf.org/mailman/listinfo/ipv6</a><br>
--------------------------------------------------------------------<br>
</blockquote></div></div></div>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic