Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt

[Gyan Mishra <[e-mail]>]

Joel

>From my experience and vendor best practice as well as operators
deployments as well have always configure ethernet interfaces with P2P
subnet /31 or /127 as network type P2P for ospf to bypass DR election
immediate converge to Full state and ISIS  to avoid  DIS election and more
efficient.

This basic IGP optimization has been done for many decades as a standard
for all operators.

As Les stated as this has been a best practice for operators I guess
forever Day 1 I would call an optimization, I am not sure the draft is
necessary as well.

There are so many configuration knob type best practices for IGP and EGP as
that also digs into vendor implementations aspects and not protocol design
or even network architecture or design, I am not sure IETF is the place for
this informational documentation.

Kind Regards

Gyan

On Thu, Jun 24, 2021 at 4:25 PM Joel Halpern Direct <
[e-mail]> wrote:

> "Needed"?  Probably not.  Almost no Informational RFCs are "needed".
> The question is whether the WG considers it useful.
>
> Yours,
> Joel
>
> On 6/24/2021 2:51 PM, Les Ginsberg (ginsberg) wrote:
> > Joel -
> >
> > Thanx for the revised version.
> > While I would still have some editorial comments to make, I think you
> have done a good job of responding to the comments made.
> >
> > The bigger question for me is whether the draft is needed at all.
> > I am still of the opinion that it is not needed.
> >
> >     Les
> >
> >
> >> -----Original Message-----
> >> From: Lsr <[e-mail]> On Behalf Of Joel M. Halpern
> >> Sent: Thursday, June 24, 2021 5:52 AM
> >> To: tom petch <[e-mail]>; [e-mail]
> >> Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
> >>
> >> Tom, please look at the latest revision and see if that helps.
> >>
> >> Also note, this document does not assign the ifType. (I.e. it does not
> >> "create an ifType".)  That is already done.
> >>
> >> Yours,
> >> Joel
> >>
> >> On 6/24/2021 7:27 AM, tom petch wrote:
> >>> From: Les Ginsberg (ginsberg) <[e-mail]>
> >>> Sent: 23 June 2021 17:38
> >>>
> >>> Joel -
> >>>
> >>> I have had concerns from the beginning as to whether this draft is
> really
> >> needed.
> >>> As I have commented previously, the only content of any significance is
> >> Section 4 - and that only provides example settings of the management
> fields
> >> for this interface type.
> >>> I question whether a draft is required for this purpose.
> >>> I will defer on this matter to folks more expert in this area than I,
> but, my
> >> opinion is that a draft solely for this purpose is not required.
> >>>
> >>> <tp>
> >>> Les has a point.  I see a relevant I-D and dive in and review it and
> do not
> >> stop to think whether or not this work justifies an RFC.  Having
> reviewed it,
> >> and having worked out what is new - as Les says, examples in Section 4
> and
> >> not much else  - I struggle to see a justification.
> >>>
> >>> The other thought that this brought to mind is why create an ifType
> value
> >> when the world has been getting on quite happily without it for 13
> years?  Is
> >> there anything that now needs a value which previously did not?  If so,
> that
> >> might be more suitable for an I-D.
> >>>
> >>> Tom Petch
> >>>
> >>>
> >>> I thought it polite to mention this before you spend the time and
> effort to
> >> produce a new version.
> >>>
> >>>      Les
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Lsr <[e-mail]> On Behalf Of tom petch
> >>>> Sent: Wednesday, June 23, 2021 1:43 AM
> >>>> To: Joel M. Halpern <[e-mail]>; Harold Liu
> >>>> <harold.liu=[e-mail]>; [e-mail]
> >>>> Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
> >>>>
> >>>> From: Joel M. Halpern <[e-mail]>
> >>>> Sent: 22 June 2021 09:57
> >>>>
> >>>> Do Les' suggested edits address your concerns.
> >>>> We will apply yor changes to the IANA considerations section.
> >>>>
> >>>> <tp>
> >>>> I would go further than Les as I suggested on Tuesday.  Perhaps it is
> time
> >> for
> >>>> a new version to comment on.
> >>>>
> >>>> Tom Petch
> >>>>
> >>>> Yours,
> >>>> Joel
> >>>>
> >>>> On 6/22/2021 4:34 AM, tom petch wrote:
> >>>>> From: Joel M. Halpern <[e-mail]>
> >>>>> Sent: 21 June 2021 15:13
> >>>>>
> >>>>> Tom, 5309 did not define the ifType.  Go read 5309.  You seem to have
> >>>>> gotten confused by the fact that the IANA entry given to 303 points
> to
> >>>>> 5309.  That was done to have some reference (with the consent of the
> >>>>> experts).   What we are doing now is providing a better reference.
> So
> >>>>> yes, this document defines how the ifType is defined.  With no
> criticism
> >>>>> of 5309, it does not define that, since it does not define the
> ifType.
> >>>>>
> >>>>> <tp>
> >>>>> Stepping back a few e-mails,
> >>>>> I have read 5309 and did point out previously that there is no IANA
> >>>> Considerations in that RFC.  What I have said and repeat here is that
> 5309
> >>>> defines the p2pOverLan type.  That is what the RFC claims and that is
> what
> >> it
> >>>> does.  You seem to think that the definition of a type is incomplete
> >> without a
> >>>> numerical value assigned to it, the SMI ifType  or YANG identity.  The
> >> concept
> >>>> of the type exists whether or not a value has been assigned to it and
> this
> >> is
> >>>> one of the places where this I-D goes wrong..
> >>>>>
> >>>>> I would say
> >>>>> Abstract
> >>>>> The p2pOverLan interface type is described in RFC5309.
> >>>>> Subsequently, this interface type has been assigned a value of 303 by
> >>>> IANA, by Expert Review.
> >>>>> This memo ....
> >>>>>
> >>>>> Well, what does it do?  Gives examples of its use?  I see nothing
> more.
> >>>>>
> >>>>> Tom Petch
> >>>>>
> >>>>> We are explicit in this draft that one of the obvious uses for this
> >>>>> ifType is to trigger 5309 behavior.
> >>>>>
> >>>>> Yours,
> >>>>> Joel
> >>>>>
> >>>>> On 6/21/2021 4:41 AM, tom petch wrote:
> >>>>>> From: Lsr <[e-mail]> on behalf of Harold Liu
> >>>> <harold.liu=[e-mail]>
> >>>>>> Sent: 21 June 2021 02:01
> >>>>>>
> >>>>>> Hi Med and All:
> >>>>>>            Thanks for your helpful comments, I have updated a new
> version
> >> 01
> >>>> to follow the comments;
> >>>>>>            The main updating is:
> >>>>>>            1. More clearly described the intend of this draft in the
> >> introduction;
> >>>>>>            2. Change the reference style;
> >>>>>>            3. Refactor the reference section to make it more
> reasonable;
> >>>>>>            4. I haven't change "IANA Consideration" at the moment
> given
> >> there
> >>>> is lots of discussion in this part and it is still up in the air, I
> will change this
> >>>> section next update the document once this part is finalized;
> >>>>>>
> >>>>>> <tp>
> >>>>>> I still think that this is an unsatisfactory I-D and would oppose
> adoption
> >> in
> >>>> its present form,
> >>>>>>
> >>>>>> It is a question of veracity.  It claims to do what others have
> already
> >> done
> >>>> and does so without reference, without acknowledgement.  Having the
> >>>> same data defined in more than one place can only create confusion, in
> >>>> future if not now.
> >>>>>>
> >>>>>> This is a pattern and starts with the Abstract and continues
> throughout
> >>>> the I-D.
> >>>>>>
> >>>>>> Thus the Abstract claims 'this defines point-to-point interface
> type'.
> >> No.
> >>>> This type was defined in RFC5309 and you need to say that and to say
> >> what if
> >>>> anything you are changing in that definition.  You should not
> reproduce
> >> text
> >>>> from that RFC unless you have to and then you should make it clear you
> >> are
> >>>> quoting.
> >>>>>>
> >>>>>> You do the same with Figure 1.  This is a copy, may be accurate may
> be
> >>>> not, it does not matter, from RFC8343 with no mention thereof.  You
> >> should
> >>>> not be reproducing such text without a good reason and then you should
> >>>> make it clear what is reproduced, from where and why.
> >>>>>>
> >>>>>> And as I have said already, IANA Considerations is yet again
> claiming to
> >> do
> >>>> what has already happened which can only confuse.  All that is needed
> as
> >> I
> >>>> said in a separate note  is to ask IANA to update two references,
> nothing
> >>>> more.
> >>>>>>
> >>>>>> Tom Petch
> >>>>>>
> >>>>>>            And I would like to share more background information
> for this
> >>>> internet draft:
> >>>>>>            As Joel mentioned, we requested and received an IF Type
> >>>> assignment from IANA (with expert review) for point-to-point over
> >> Ethernet
> >>>> links several weeks ago and the p2pOverLan type is already added to
> >> IANA
> >>>> registry now;
> >>>>>>            During the discussion around the assignment we noticed a
> doc
> >>>> describing why that is needed and how to use that would be helpful;
> >>>>>>            For example, if no entry saying p2pOverLan layer over
> ethernet,
> >> the
> >>>> management will suffer since lose the ability to get to the Ethernet-
> >> specific
> >>>> management properties (Ethernet MIB or YANG model) via many tools;
> >> So
> >>>> we propose this draft to define a complete p2pOverLan
> ifStack(Including
> >>>> higher layer and lower layer);
> >>>>>>
> >>>>>> Brs
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: [e-mail]
> >>>> <[e-mail]>
> >>>>>> Sent: Thursday, June 17, 2021 2:16 PM
> >>>>>> To: Joel M. Halpern <[e-mail]>; draft-liu-lsr-
> >>>> [e-mail]
> >>>>>> Subject: RE: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
> >>>>>>
> >>>>>> Hi Joel, all,
> >>>>>>
> >>>>>> Please find some quick comments to this draft, fwiw:
> >>>>>>
> >>>>>> * pdf: https://protect2.fireeye.com/v1/url?k=e8e7d1aa-b77ce948-
> >>>> e8e79131-86073b36ea28-edbd778070bbec9a&q=1&e=d4a020c9-b337-
> >> 41fd-
> >>>> bf1b-
> >> 56dcfaef1044&u=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-
> >>>> Drafts-Reviews%2Fblob%2Fmaster%2Fdraft-liu-lsr-p2poverlan-00-
> >>>> rev%2520Med.pdf
> >>>>>> * doc: https://protect2.fireeye.com/v1/url?k=938b5849-cc1060ab-
> >>>> 938b18d2-86073b36ea28-e0406a2599fa2a6d&q=1&e=d4a020c9-b337-
> >> 41fd-
> >>>> bf1b-
> >> 56dcfaef1044&u=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-
> >>>> Drafts-Reviews%2Fraw%2Fmaster%2Fdraft-liu-lsr-p2poverlan-00-
> >>>> rev%2520Med.docx
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Med
> >>>>>>
> >>>>>>> -----Message d'origine-----
> >>>>>>> De : Lsr [mailto:[e-mail]] De la part de Joel M.
> Halpern
> >>>>>>> Envoyé : mercredi 16 juin 2021 22:47 À : Acee Lindem (acee)
> >>>>>>> <[e-mail]>; [e-mail] Objet : Re: [Lsr] Fwd: I-D Action:
> >>>>>>> draft-liu-lsr-p2poverlan-00.txt
> >>>>>>>
> >>>>>>> This document (and the code point) are intended to be in line with
> >>>>>>> 5309.
> >>>>>>>       I believe they are.  If we got it wrong, please help us fix
> it.
> >>>>>>>
> >>>>>>> A reference would be reasonable to add.  (The IANA entry for the
> >> code
> >>>>>>> point does reference 5309.)
> >>>>>>>
> >>>>>>> Thank you,
> >>>>>>> Joel
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 6/16/2021 4:41 PM, Acee Lindem (acee) wrote:
> >>>>>>>> Hi Joel,
> >>>>>>>>
> >>>>>>>> At first I wondered where this document should reside and then
> >>>>>>> decided that LSR is probably as good as any other place.
> >>>>>>>>
> >>>>>>>> Can you guys check whether it is mostly in line with
> >>>>>>> https://datatracker.ietf.org/doc/rfc5309/ and comment as to
> whether
> >> it
> >>>>>>> should be referenced?
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Acee
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 6/16/21, 11:10 AM, "Lsr on behalf of Joel M. Halpern" <lsr-
> >>>>>>> [e-mail] on behalf of [e-mail]> wrote:
> >>>>>>>>
> >>>>>>>>          Recently, Ericsson requested and received an IF Type
> >>>>>>> assignment from
> >>>>>>>>          IANA (with expert review) for point-to-point over
> Ethernet
> >>>>>>> links.
> >>>>>>>>
> >>>>>>>>          It was noted during the discussion around the assignment
> that
> >>>>>>> a document
> >>>>>>>>          (eventually, we hope, an RFC) describing how to use that
> and
> >>>>>>> why we
> >>>>>>>>          asked for it would be helpful.
> >>>>>>>>
> >>>>>>>>          The below announcement is that draft.  We would like to
> work
> >>>>>>> with the
> >>>>>>>>          community to improve and clarify teh draft.
> >>>>>>>>
> >>>>>>>>          Thank you,
> >>>>>>>>          Joel
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>          -------- Forwarded Message --------
> >>>>>>>>          Subject: I-D Action: draft-liu-lsr-p2poverlan-00.txt
> >>>>>>>>          Date: Wed, 16 Jun 2021 07:00:04 -0700
> >>>>>>>>          From: [e-mail]
> >>>>>>>>          Reply-To: [e-mail]
> >>>>>>>>          To: [e-mail]
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>          A New Internet-Draft is available from the on-line
> Internet-
> >>>>>>> Drafts
> >>>>>>>>          directories.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>                   Title           : Interface Stack Table
> Definition
> >>>>>>> for Point to
> >>>>>>>>          Point (P2P) Interface over LAN
> >>>>>>>>                   Authors         : Daiying Liu
> >>>>>>>>                                     Joel Halpern
> >>>>>>>>                                     Congjie Zhang
> >>>>>>>>                 Filename        : draft-liu-lsr-p2poverlan-00.txt
> >>>>>>>>                 Pages           : 7
> >>>>>>>>                 Date            : 2021-06-16
> >>>>>>>>
> >>>>>>>>          Abstract:
> >>>>>>>>              The point-to-point circuit type is one of the mainly
> used
> >>>>>>> circuit
> >>>>>>>>              types in link state routing protocol.  It is
> important to
> >>>>>>> identify
> >>>>>>>>              the correct circuit type when forming adjacencies,
> >>>>>>> flooding link
> >>>>>>>>              state database packets, and monitor the link state.
> This
> >>>>>>> document
> >>>>>>>>              defines point-to-point interface type and relevant
> stack
> >>>>>>> tables to
> >>>>>>>>              provide benefit for operation, maintenance and
> >>>>>>> statistics.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>          The IETF datatracker status page for this draft is:
> >>>>>>>>
> https://datatracker.ietf.org/doc/draft-liu-lsr-p2poverlan/
> >>>>>>>>
> >>>>>>>>          There is also an htmlized version available at:
> >>>>>>>>          https://datatracker.ietf.org/doc/html/draft-liu-lsr-
> >>>>>>> p2poverlan-00
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>          Internet-Drafts are also available by anonymous FTP at:
> >>>>>>>>          ftp://ftp.ietf.org/internet-drafts/
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>          _______________________________________________
> >>>>>>>>          I-D-Announce mailing list
> >>>>>>>>          [e-mail]
> >>>>>>>>          https://www.ietf.org/mailman/listinfo/i-d-announce
> >>>>>>>>          Internet-Draft directories:
> http://www.ietf.org/shadow.html
> >>>>>>>>          or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>>>>>>>
> >>>>>>>>          _______________________________________________
> >>>>>>>>          Lsr mailing list
> >>>>>>>>          [e-mail]
> >>>>>>>>          https://www.ietf.org/mailman/listinfo/lsr
> >>>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Lsr mailing list
> >>>>>>> [e-mail]
> >>>>>>> https://www.ietf.org/mailman/listinfo/lsr
> >>>>>>
> >>>>>>
> >>>>
> >> __________________________________________________________
> >>>>
> >> __________________________________________________________
> >>>> _____
> >>>>>>
> >>>>>> 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.
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Lsr mailing list
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/lsr
> >>>>>> _______________________________________________
> >>>>>> Lsr mailing list
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/lsr
> >>>>>>
> >>>> _______________________________________________
> >>>> Lsr mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/lsr
> >>
> >> _______________________________________________
> >> Lsr mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/lsr
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*