Re: FW: New Version Notification for draft-bonica-6man-ext-hdr-update-00.txt

Ron

I agree this is a much needed update to RFC 8200 to tighten up the
verbiage.  I agree with Tom’s comments on the draft.

In Tom’s comment about destination versus final destination that is
important clarity as far as hop by hop steering with SID copied to DA, you
don’t want the hop by hop DA copied during SRH processing to be confused
with final destination node.  As far final destination in the SR use case
it would be a closed domain being the SP operators core.  However the
customer payload tunneled through the operator domain would actually
terminate outside the Operators domain within the customer network and
could also have an RH that should also follow the RFC 8200 rules as to
final destination of the packet within the customer network.

I think the main use case is for operators and SR but since this is the
IPv6 specification we are updating it should account for all final
 destination use cases for RH processing and what is allowed and what is
forbidden.

Kind regards

Gyan

On Fri, Mar 6, 2020 at 7:36 PM Ron Bonica <rbonica=
40juniper.net@dmarc.ietf.org> wrote:

> Hi Tom,
>
> Thanks for the review. Comments inline.....
>
>                                 Ron
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: Tom Herbert <tom@herbertland.com>
> Sent: Friday, March 6, 2020 6:25 PM
> To: Ron Bonica <rbonica@juniper.net>
> Cc: 6man@ietf.org
> Subject: Re: FW: New Version Notification for
> draft-bonica-6man-ext-hdr-update-00.txt
>
> Ron,
>
> Thanks for the draft!
>
> I suggest to define the term "final destination" as opposed to just
> "destination" out of an abundance of clarity. Note that the Destination
> address isn't necessarily the address of the final destination, and
> similarly Destination Options (before the routing
> header) may be processed by nodes other than the final destination.
>
> [RB] Fair enough. Maybe final destination or ultimate destination.
>
>
> I don't understand why this particular requirement is needed:
> "However, if the packet does not include a Fragment header, the
> Authentication header and Encapsulating Security Payload header can be
> processed by any segment egress node, including the destination node."
>
> My interpretation of the intent of RFC8200 is that:
> - All nodes in the path can process Hop-by-hop options
> - Segment egress nodes can process Hop-by-hop options, Destination Options
> before routing header, and the Routing header (that is unless the segment
> egress node is also the final destination it does not process any of the
> packet beyond the routing header)
> - Final destinations process all packet headers
>
> [RB] You are correct. I will fix this right away.
>
> "Process" here does not include inserting or deleting extension headers.
> It may include modifications that are done on fields explicitly declared to
> be mutable.
>
> [RB] Yes. I will clarify that.
>
> Tom
>
> On Fri, Mar 6, 2020 at 2:45 PM Ron Bonica <rbonica=
> 40juniper.net@dmarc.ietf.org> wrote:
> >
> >
> > Please review and comment.
> >
> >
> >
> > Juniper Business Use Only
> >
> > -----Original Message-----
> > From: internet-drafts@ietf.org <internet-drafts@ietf.org>
> > Sent: Friday, March 6, 2020 5:41 PM
> > To: Ron Bonica <rbonica@juniper.net>
> > Subject: New Version Notification for
> > draft-bonica-6man-ext-hdr-update-00.txt
> >
> >
> > A new version of I-D, draft-bonica-6man-ext-hdr-update-00.txt
> > has been successfully submitted by Ron Bonica and posted to the IETF
> repository.
> >
> > Name:           draft-bonica-6man-ext-hdr-update
> > Revision:       00
> > Title:          Inserting, Processing And Deleting IPv6 Extension Headers
> > Document date:  2020-03-06
> > Group:          Individual Submission
> > Pages:          5
> > URL:
> https://urldefense.com/v3/__https://www.ietf.org/internet-drafts/draft-bonica-6man-ext-hdr-update-00.txt__;!!NEt6yMaO-gk!U5D_phraIxAwKqMrWDSa87_at2DUci9QUmKtH1rE42HmEbybR6X9Wsq15vGrEd2Y$
> > Status:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-6man-ext-hdr-update/__;!!NEt6yMaO-gk!U5D_phraIxAwKqMrWDSa87_at2DUci9QUmKtH1rE42HmEbybR6X9Wsq15hjd1VtT$
> > Htmlized:
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-6man-ext-hdr-update-00__;!!NEt6yMaO-gk!U5D_phraIxAwKqMrWDSa87_at2DUci9QUmKtH1rE42HmEbybR6X9Wsq15vJvzWAw$
> > Htmlized:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-bonica-6man-ext-hdr-update__;!!NEt6yMaO-gk!U5D_phraIxAwKqMrWDSa87_at2DUci9QUmKtH1rE42HmEbybR6X9Wsq15mbBPBWx$
> >
> >
> > Abstract:
> >    This document provides guidance regarding the processing, insertion
> >    and deletion of IPv6 extension headers.  It updates RFC 8200.
> >
> >
> >
> >
> > 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.
> >
> > The IETF Secretariat
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests:
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> > __;!!NEt6yMaO-gk!U5D_phraIxAwKqMrWDSa87_at2DUci9QUmKtH1rE42HmEbybR6X9W
> > sq15imVyTZZ$
> > --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com