Subject: [Isis-wg] AD review of draft-ietf-isis-mi-bis-01

From: Alia Atlas <[email-masked]>
Date: Fri, 17 Mar 2017 11:46:48 -0400

As is customary, I have done my AD review of draft-ietf-isis-mi-bis-01.
First, I would like to thank the authors - Les, Stefano, and Wim - for
their work on this document.

I do have a few minor issues that need to be fixed ASAP.   I will, however,
go ahead and issue a 3 week IETF Last Call for it so that, if the authors
act promptly, it can be on the April 13 telechat.

1) This draft pretty clearly should obsolete RFC 6822, but the header
claims to merely
update it.

 2) Sec 2.6.2: " Point-to-point adjacency setup MUST be done through the
use of the
         three-way handshaking procedure as defined in [RFC5303] in order to
         prevent a non-MI capable neighbor from bringing up an adjacency
         prematurely based on reception of an IIH with an IID-TLV for a non-
         zero instance."
     While obviously the 3-way handshake in RFC5303 is fine, given that
different MAC addresses are used, I don't see how a non-MI capable neighbor
would receive and process an IIH with an IID-TLV where IID != 0.

3) In Appendix A:" Clarification that the IID-TLV is only included in Pt-Pt
IIHs
   associated with non-zero instances has been added.  This addresses
   Errata ID #4519."
   In Sec 2.6.2, it says "The presence or absence of the IID-TLV in an IIH
indicates that the
   neighbor does or does not support this extension, respectively.
   Therefore, all IIHs sent on a point-to-point circuit by an MI-RTR
   MUST include an IID-TLV.  This includes IIHs associated with IID #0."
which is a direct
   contradiction and needed since the IID-TLV is used as a capability
indication.  The
   simplest solution is to remove the claim from the Appendix.

4) In the IANA considerations, the references should be updated to point to
this document, and most particularly if it obsoletes RFC 6822.

Regards,
Alia

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 17 Mar 2017 17:57:05 +0000

Alia –

Thanx for meticulous review.
Inline.

From: Alia Atlas [mailto:[email-masked]]
Sent: Friday, March 17, 2017 8:47 AM
To: [email-masked]; [email-masked]
Subject: AD review of draft-ietf-isis-mi-bis-01

As is customary, I have done my AD review of draft-ietf-isis-mi-bis-01.  First, I would like to thank the authors - Les, Stefano, and Wim - for their work on this document.

I do have a few minor issues that need to be fixed ASAP.   I will, however, go ahead and issue a 3 week IETF Last Call for it so that, if the authors act promptly, it can be on the April 13 telechat.

1) This draft pretty clearly should obsolete RFC 6822, but the header claims to merely
update it.

[Les:] OK

 2) Sec 2.6.2: " Point-to-point adjacency setup MUST be done through the use of the
         three-way handshaking procedure as defined in [RFC5303] in order to
         prevent a non-MI capable neighbor from bringing up an adjacency
         prematurely based on reception of an IIH with an IID-TLV for a non-
         zero instance."
     While obviously the 3-way handshake in RFC5303 is fine, given that different MAC addresses are used, I don't see how a non-MI capable neighbor would receive and process an IIH with an IID-TLV where IID != 0.

[Les:] Section 2.6.2 is only talking about true pt-pt media – hence MAC multicast addresses are not relevant. In Section 2.6.1 we discuss the case of operating in Pt-Pt mode on a broadcast circuit:

“When operating in point-to-point mode on a broadcast circuit
   [RFC5309]…”

3) In Appendix A:" Clarification that the IID-TLV is only included in Pt-Pt IIHs
   associated with non-zero instances has been added.  This addresses
   Errata ID #4519."
   In Sec 2.6.2, it says "The presence or absence of the IID-TLV in an IIH indicates that the
   neighbor does or does not support this extension, respectively.
   Therefore, all IIHs sent on a point-to-point circuit by an MI-RTR
   MUST include an IID-TLV.  This includes IIHs associated with IID #0." which is a direct
   contradiction and needed since the IID-TLV is used as a capability indication.  The
   simplest solution is to remove the claim from the Appendix.
[Les:] Again, you are confusing Pt-Pt media with Pt-Pt operation on a Broadcast media. Errata 4519 is concerned with Pt-Pt operation on a LAN – and some modest clarifications in Section 2.6.1 were made to more completely cover the latter case.
In the Pt-Pt operation on a LAN case it IS illegal to send IID-TLV in hellos for the zero instance – which Section 2.6.1 explicitly states.

Perhaps the Appendix should say:

“Clarification that when operating in point-to-point mode on a broadcast circuit the IID-TLV is only included in Pt-Pt IIHs
   associated with non-zero instances has been added. ..”

Will this address your concern?

4) In the IANA considerations, the references should be updated to point to this document, and most particularly if it obsoletes RFC 6822.

[Les:] Agreed. I did not think I had to state that – I assumed IANA would just do that – but I am happy to add a line in IANA section stating that all references to RFC 6822 should be updated to point to this document.

Let me know if the above changes will suffice and I will spin a new version.

   Les

Regards,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Fri, 17 Mar 2017 14:13:19 -0400

Hi Les,

On Fri, Mar 17, 2017 at 1:57 PM, Les Ginsberg (ginsberg) <[email-masked]
> wrote:

> *From:* Alia Atlas [mailto:[email-masked]]
> *Sent:* Friday, March 17, 2017 8:47 AM
> *To:* [email-masked]; [email-masked]
> *Subject:* AD review of draft-ietf-isis-mi-bis-01
>
>
>
> I do have a few minor issues that need to be fixed ASAP.   I will,
> however, go ahead and issue a 3 week IETF Last Call for it so that, if the
> authors act promptly, it can be on the April 13 telechat.
>
>
>
>
>
> *[Les:] OK*
> *[Les:] Section 2.6.2 is only talking about true pt-pt media – hence MAC
> multicast addresses are not relevant. In Section 2.6.1 we discuss the case
> of operating in Pt-Pt mode on a broadcast circuit:*
>
>
>
> *“When operating in point-to-point mode on a broadcast circuit*
>
> *   [RFC5309]…”*
>

Thanks - you are completely correct.

 3) In Appendix A:" Clarification that the IID-TLV is only included in
> Pt-Pt IIHs
> *[Les:] Again, you are confusing Pt-Pt media with Pt-Pt operation on a
> Broadcast media. Errata 4519 is concerned with Pt-Pt operation on a LAN –
> and some modest clarifications in Section 2.6.1 were made to more
> completely cover the latter case.*
>
> *In the Pt-Pt operation on a LAN case it IS illegal to send IID-TLV in
> hellos for the zero instance – which Section 2.6.1 explicitly states.*
>
>
>
> *Perhaps the Appendix should say:*
>
>
>
> *“Clarification that when operating in point-to-point mode on a broadcast
> circuit the IID-TLV is only included in Pt-Pt IIHs*
>
> *   associated with non-zero instances has been added. ..”*
>
>
>
> *Will this address your concern?*
>

Yes, I didn't go and look up Errata ID #4519 to catch the context of
pt-to-pt on broadcast only.   That would make it more of a nit than a minor
issue, of course.

This all does imply that:
   a) IIH with IID=0 is a capability advertisement for pt-to-pt links but
not pt-to-pt on broadcast.
   b) It is never ok (discarded by receiver) to send an IIH with IID=0 on a
pt-to-pt on broadcast.
   c) The capability indicator for being an MI-RTR on a pt-to-pt on
broadcast link is whether or not the ALLL1MI-IS or ALLL2MI-IS is listened
to or sent on.

I know there is real code and deployments behind this - but that's a bit
confusing for trouble-shooting & it would be nice to have it more clearly
articulated.

> 4) In the IANA considerations, the references should be updated to point
> to this document, and most particularly if it obsoletes RFC 6822.
>
>
>
> *[Les:] Agreed. I did not think I had to state that – I assumed IANA would
> just do that – but I am happy to add a line in IANA section stating that
> all references to RFC 6822 should be updated to point to this document.*
>

Yes - we need to do that.

Incidentally, on another reread (checking the above issues) is there a
reason that
"The destination multicast address is one of the two new addresses
 and the PDU contains an IID-TLV with a zero value for the IID or
 has no IID-TLV."

doesn't simply name the addresses (ALLL1MI-IS or ALLL2MI-IS)?  I think
that'd be clearer - but this is definitely nit.

> *Let me know if the above changes will suffice and I will spin a new
> version.*
>

Sounds good.

Thanks,
Alia

> *   Les*

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 17 Mar 2017 18:14:50 +0000

>[Les:] Agreed. I did not think I had to state that – I assumed IANA would just do that – but I am happy to add a line in IANA section stating that all references to RFC 6822 should be updated to poi…

Quick comment:

Currently document says it updates 6822 – which is correct?

-          I can guess but want to hear author thoughts..

--
Uma C.

From: Isis-wg [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Friday, March 17, 2017 10:57 AM
To: Alia Atlas <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Isis-wg] AD review of draft-ietf-isis-mi-bis-01

Alia –

From: Alia Atlas [mailto:[email-masked]]
Sent: Friday, March 17, 2017 8:47 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: AD review of draft-ietf-isis-mi-bis-01

[Les:] OK

   Les

Regards,
Alia

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 17 Mar 2017 18:30:20 +0000

Uma –

I agree w Alia’s evaluation that this replaces RFC 6822.

   Les

From: Uma Chunduri [mailto:[email-masked]]
Sent: Friday, March 17, 2017 11:15 AM
To: Les Ginsberg (ginsberg); Alia Atlas; [email-masked]; [email-masked]
Subject: RE: AD review of draft-ietf-isis-mi-bis-01

Quick comment:

--
Uma C.

From: Isis-wg [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Friday, March 17, 2017 10:57 AM
To: Alia Atlas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Isis-wg] AD review of draft-ietf-isis-mi-bis-01

Alia –

[Les:] OK

   Les

Regards,
Alia

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 17 Mar 2017 18:39:16 +0000

Alia  -

From: Alia Atlas [mailto:[email-masked]]
Sent: Friday, March 17, 2017 11:13 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]; [email-masked]
Subject: Re: AD review of draft-ietf-isis-mi-bis-01

Hi Les,

On Fri, Mar 17, 2017 at 1:57 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Alia –

From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, March 17, 2017 8:47 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: AD review of draft-ietf-isis-mi-bis-01

[Les:] OK

Yes, I didn't go and look up Errata ID #4519 to catch the context of pt-to-pt on broadcast only.   That would make it more of a nit than a minor issue, of course.

This all does imply that:
   a) IIH with IID=0 is a capability advertisement for pt-to-pt links but not pt-to-pt on broadcast.
   b) It is never ok (discarded by receiver) to send an IIH with IID=0 on a pt-to-pt on broadcast.
   c) The capability indicator for being an MI-RTR on a pt-to-pt on broadcast link is whether or not the ALLL1MI-IS or ALLL2MI-IS is listened to or sent on.

I know there is real code and deployments behind this - but that's a bit confusing for trouble-shooting & it would be nice to have it more clearly articulated.
[Les:] From Section 2.6.1:

  MI-RTRs MUST discard IS-IS PDUs received if either of the following
   is true:

   o  The destination multicast address is AllL1IS, AllL2IS, or AllIS
      and the PDU contains an IID-TLV

   o  The destination multicast address is one of the two new addresses
      and the PDU contains an IID-TLV with a zero value for the IID or
      has no IID-TLV.

From Section 2.6.2:

   The presence or absence of the IID-TLV in an IIH indicates that the
   neighbor does or does not support this extension, respectively.
   Therefore, all IIHs sent on a point-to-point circuit by an MI-RTR
     MUST include an IID-TLV.  This includes IIHs associated with IID #0.

[Les:] I think this language is very precise.
It is true that operation in Point-to-point mode on a broadcast media is subtly different than operation on true P2P media – which is why we discuss the two in different sections.
??

Incidentally, on another reread (checking the above issues) is there a reason that
"The destination multicast address is one of the two new addresses
 and the PDU contains an IID-TLV with a zero value for the IID or
 has no IID-TLV."

doesn't simply name the addresses (ALLL1MI-IS or ALLL2MI-IS)?  I think that'd be clearer - but this is definitely nit.

[Les:] Happy to explicitly call out the specific addresses in the second bullet.

   Les

Sounds good.

Thanks,
Alia

   Les

Regards,
Alia

---

From: Alexander Okonnikov <[email-masked]>
Date: Fri, 17 Mar 2017 21:40:25 +0300

Hi Alia and authors,

Regarding point 2): This was root of my confusion and reason for submitting Errata ID #4521. Per my understanding a IS-IS circuit is a representaion of layer 2 link for IS-IS, and not a physical circuit itself. For mentioning type of physical media ISO 10589:2002 has another term subnetwork. Early versions of draft-ietf-isis-mi used term "network" (up to -04), which was replaced by "circuit" later. In my mind, term "circuit" creates ambiguity. From IS-IS point of view regular P2P circuit and P2PoverLAN circuit are both P2P circuits. May be it is better to create dedicated section for P2PoverLAN "circuits" to avoid confusion.

Errata ID #4520 was not incorporated fully. Info regarding AllIS MAC was added, but -bis still clarifies usage of standard MACs (for standard instance) and new ones (for non-zero instances) only for IIHs in P2PoverLAN mode. I.e. the draft doesn't specify which MACs should be used for SNPs and LSPs in that mode. From current text we can conclude that for standard instance addresses AllL1IS and AllL2IS could be used on P2PoverLAN. But AllIS could be used as well, and not only for IIH. That is why the errata mentions "PDU", rather than "IIH".

Thank you.

Alexander

On 17 марта 2017 г., 21:39 +0300, Les Ginsberg (ginsberg) <[email-masked]>, wrote:
> On Fri, Mar 17, 2017 at 1:57 PM, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> Alia –
>
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 17 Mar 2017 18:45:23 +0000

Les,

Thx for the clarification.

I too agree on this (couldn’t notice this earlier more thoroughly..) and in that case why original authors were completely replaced with new set of folks as opposed to adding?

W.r.t. this, why we how to do this differently while numerous other WGs just do the addition and the ratified changes to the original document.

My view is we need not be different here but would be happy to listen from you, AD and other esteemed members of this group.

--
Uma C.

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Friday, March 17, 2017 11:30 AM
To: Uma Chunduri <[email-masked]>; Alia Atlas <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: AD review of draft-ietf-isis-mi-bis-01

Uma –

   Les

From: Uma Chunduri [mailto:[email-masked]]
Sent: Friday, March 17, 2017 11:15 AM
To: Les Ginsberg (ginsberg); Alia Atlas; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: AD review of draft-ietf-isis-mi-bis-01

Quick comment:

--
Uma C.

Alia –

[Les:] OK

   Les

Regards,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Fri, 17 Mar 2017 14:59:01 -0400

Hi Les,

On Fri, Mar 17, 2017 at 2:39 PM, Les Ginsberg (ginsberg) <[email-masked]

> *Sent:* Friday, March 17, 2017 11:13 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: AD review of draft-ietf-isis-mi-bis-01
>
>
>
> Hi Les,
>
>
>
> *   [RFC5309]…” *
> *[Les:] From Section 2.6.1:*
>
>
>
> *[Les:] I think this language is very precise.*
>
> *It is true that operation in Point-to-point mode on a broadcast media is
> subtly different than operation on true P2P media – which is why we discuss
> the two in different sections.*
>
> ??
>

Yes, I agree that there isn't a technical gap.  What I was hoping for is a
bit of clarity
for an operator or someone troubleshooting.  Normally, I'd expect the same
information being sent across a pt-to-pt link, regardless of whether it was
over broadcast or not.

There's also the aspect of sending consistently the IIH with IID!=0 on a
pt-to-pt broadcast b/c there's no way other than a response of telling that
the neighbor has changed to be an MI-RTR.

I'm thinking of text like the following - and feel free to
modify/reject/improve, but sometimes text helps clarify.

"An MI-RTR detects the capability of its neighbor to also be an MI-RTR
differently based upon the type of link.  For a point-to-point broadcast
link, an MI-RTR that is configured to support instances beyond the IID=0
will periodically send out IIHs with an IID-TLV to either ALLL1MI-IS or
ALLL2MI-IS; if a corresponding IIH with a matching IID-TLV is received,
then a neighbor adjacency formation for that IIH can proceed.  If a router
is not configured to support additional instances between IID=0, it is not
possible to determine, based on protocol traffic, whether that router is an
MI-RTR.

Differences in configuration can be determined by examining the IIHs sent
on ALLL1MI-IS or ALLL2MI-IS.  For a point-to-point circuit, an MI-RTR that
is configured to support MI will include an IID-TLV with IID=0 in its IIH.
  If the receiving router doesn't recognize the IID-TLV or is not
configured to be an MI-RTR, then the IID-TLV will simply be discarded.  If
there is a difference in configuration to be an MI-RTR, that can be
determined by examining whether the IIH includes an IID-TLV where the
IID=0.  However, determining differences in configuration for additional
IIDs cannot be done based on protocol traffic until both routers recognize
that their neighbor is an MI-RTR."

Basically, for one type of link, it is possible to tell the capability but
not the instances and for the other it is possible to tell the instances,
but not the capability.

Frankly, the proposed text above feels too long to me - so please do
improve it!

Regards,
Alia

> *[Les:] Happy to explicitly call out the specific addresses in the second
> bullet.*
>
>
>
> *   Les*
>
>
>

---

From: Alia Atlas <[email-masked]>
Date: Fri, 17 Mar 2017 15:04:37 -0400

Hi Alexander,

On Fri, Mar 17, 2017 at 2:40 PM, Alexander Okonnikov <
[email-masked]> wrote:

> Hi Alia and authors,
>
> Regarding point 2): This was root of my confusion and reason for
> submitting Errata ID #4521. Per my understanding a IS-IS circuit is a
> representaion of layer 2 link for IS-IS, and not a physical circuit itself.
> For mentioning type of physical media ISO 10589:2002 has another term
> subnetwork. Early versions of draft-ietf-isis-mi used term "network" (up to
> -04), which was replaced by "circuit" later. In my mind, term "circuit"
> creates ambiguity. From IS-IS point of view regular P2P circuit and
> P2PoverLAN circuit are both P2P circuits. May be it is better to create
> dedicated section for P2PoverLAN "circuits" to avoid confusion.
>

A subsection in 2.6.1 that clarifies it is for point-to-point over
broadcast would help clarify that sec 2.6.1 is intended to apply rather
than sec 2.6.2.

> Errata ID #4520 was not incorporated fully. Info regarding AllIS MAC was
> added, but -bis still clarifies usage of standard MACs (for standard
> instance) and new ones (for non-zero instances) only for IIHs in P2PoverLAN
> mode. I.e. the draft doesn't specify which MACs should be used for SNPs and
> LSPs in that mode. From current text we can conclude that for standard
> instance addresses AllL1IS and AllL2IS could be used on P2PoverLAN. But
> AllIS could be used as well, and not only for IIH. That is why the errata
> mentions "PDU", rather than "IIH".
>

In Sec 2.6.1, I see the following:

" When sending SNPs, LSPs, and LAN IIHs for the standard instance (IID

   #0) an MI-RTR will use the AllL1IS and AllL2IS ISIS MAC layer
   addresses (as defined in [ISO10589]) as the destination address.
   When sending SNPs, LSPs, and LAN IIHs for any non-zero IID an MI-RTR
   will use one of two new dedicated layer 2 multicast addresses
   (AllL1MI-ISs or AllL2MI- IS) as the destination address.  These
   addresses are specified in Section 6.

   When operating in point-to-point mode on a broadcast circuit
   [RFC5309], an MI-RTR will use AllL1IS, AllL2IS, or AllIS MAC-layer
   address when sending point-to-point IIHs associated with the standard
   instance.  When sending point-to-point IIHs for a non-zero IID an MI-
   RTR MUST use one of the two new multicast addresses (AllL1MI-ISs or
   AllL2MI- IS) as the destination address (either address will do).
"

This could be cleaned up a bit.

Alia

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 17 Mar 2017 19:55:31 +0000

Alexander –

From: Alexander Okonnikov [mailto:[email-masked]]
Sent: Friday, March 17, 2017 11:40 AM
To: Alia Atlas; Les Ginsberg (ginsberg)
Cc: [email-masked]; [email-masked]
Subject: Re: [Isis-wg] AD review of draft-ietf-isis-mi-bis-01

Hi Alia and authors,

[Les:] The word “circuit” was chosen precisely because it is the term used in ISO 10589. You could start with ISO 10589 Section 3.6.3 – and then examine the hundreds of other uses of the term in the document.

[Les:] RFC 5309 is relaxed in its language on this point. It says (Section 4.1):

“The Multi-destination address including AllISs, AllL1ISs, and
   AllL2ISs, defined in [ISO10589], can be used for link-layer
   encapsulation; the use of AllISs is recommended.”

I have always interpreted this to mean use AllIS for hellos – because Pt2Pt IIHs are not level specific – but use the L1/L2 addresses for SNPs/LSPs which are level specific.
However, a strict interpretation of RFC 5309 allows that AllISs could be used for SNPs/LSPs. I will correct that omission.

However, we did add text specifying the PDU types explicitly, so I believe any confusion on that point has been addressed.

   Les

Thank you.

Alexander

On 17 марта 2017 г., 21:39 +0300, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>, wrote:

Alia  -

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Les,

[Les:] OK

From Section 2.6.2:

   Les

Sounds good.

Thanks,
Alia

   Les

Regards,
Alia

_______________________________________________
Isis-wg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 17 Mar 2017 20:05:07 +0000

Uma –

I am not aware of any requirement to have the original set of authors be authors of a bis document – and there are certainly other examples where authorship has changed. And there are obvious practical reasons why authorship may change.

The authors of the bis draft are the ones who actively participated in the writing of the bis draft. The fact that some of the authors of RFC 6822 did not participate in the writing of the bis draft  in no way diminishes their past contributions which are permanently recorded in RFC 6822.

I’ll let Alia take it from here from an official IETF process standpoint.

   Les

From: Uma Chunduri [mailto:[email-masked]]
Sent: Friday, March 17, 2017 11:45 AM
To: Les Ginsberg (ginsberg); Alia Atlas; [email-masked]; [email-masked]
Subject: RE: AD review of draft-ietf-isis-mi-bis-01

Les,

--
Uma C.

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Friday, March 17, 2017 11:30 AM
To: Uma Chunduri <[email-masked]<mailto:[email-masked]>>; Alia Atlas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: AD review of draft-ietf-isis-mi-bis-01

Uma –

   Les

Quick comment:

--
Uma C.

Alia –

[Les:] OK

   Les

Regards,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Fri, 17 Mar 2017 16:34:26 -0400

Uma,

Les has already said it.  It is common to have a section that mentions and
thanks the authors of the original RFC when a bis version is done with
different authors.

Keeping the previous authors can cause issues for reviews and approvals
later on.

Regards,
Alia

On Fri, Mar 17, 2017 at 4:05 PM, Les Ginsberg (ginsberg) <[email-masked]

> Uma –
>
>
>
> I am not aware of any requirement to have the original set of authors be
> authors of a bis document – and there are certainly other examples where
> authorship has changed. And there are obvious practical reasons why
> authorship may change.
>
>
>
> The authors of the bis draft are the ones who actively participated in the
> writing of the bis draft. The fact that some of the authors of RFC 6822 did
> not participate in the writing of the bis draft  in no way diminishes their
> past contributions which are permanently recorded in RFC 6822.
>
>
>
> *From:* Uma Chunduri [mailto:[email-masked]]
> *Sent:* Friday, March 17, 2017 11:45 AM
>
> *To:* Les Ginsberg (ginsberg); Alia Atlas; [email-masked];
> [email-masked]
> *Subject:* RE: AD review of draft-ietf-isis-mi-bis-01
>
>
>
> Les,
>
>
>
> I too agree on this (couldn’t notice this earlier more thoroughly..) and
> in that case why original authors were completely replaced with new set of
> folks as opposed to adding?
>
>
>
> W.r.t. this, why we how to do this differently while numerous other WGs
> just do the addition and the ratified changes to the original document.
>
>
>
> My view is we need not be different here but would be happy to listen from
> you, AD and other esteemed members of this group.
>
>
>
> --
>
> Uma C.
>
>
>
> *From:* Les Ginsberg (ginsberg) [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Friday, March 17, 2017 11:30 AM
> *To:* Uma Chunduri <[email-masked]>; Alia Atlas <
> [email-masked]>; [email-masked]; [email-masked]
> *Subject:* RE: AD review of draft-ietf-isis-mi-bis-01
>
>
>
> Uma –
>
>
>
> *From:* Uma Chunduri [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Friday, March 17, 2017 11:15 AM
> *To:* Les Ginsberg (ginsberg); Alia Atlas; [email-masked];
> [email-masked]
> *Subject:* RE: AD review of draft-ietf-isis-mi-bis-01
>
>
>
> >*[Les:] Agreed. I did not think I had to state that – I assumed IANA
> would just do that – but I am happy to add a line in IANA section stating
> that all references to RFC 6822 should be updated to point to this
> document.*
>
>
>
> Quick comment:
>
>
>
> *From:* Isis-wg [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Les Ginsberg (ginsberg)
> *Sent:* Friday, March 17, 2017 10:57 AM
> *To:* Alia Atlas <[email-masked]>; [email-masked];
> [email-masked]
> *Subject:* Re: [Isis-wg] AD review of draft-ietf-isis-mi-bis-01
>
>
>
> Alia –
>
>
>
> *From:* Alia Atlas [mailto:[email-masked] <[email-masked]>]

---

From: Alexander Okonnikov <[email-masked]>
Date: Fri, 17 Mar 2017 23:31:21 +0300

Les,

Exactly, I examined 10589, and there medium-dependent aspects are mentioned using "subnetwork" term or "link". "Subnetwork-dependent" and "subnetwork-independent", "broadcast subnetworks", "general topology subnetworks", where "point-to-point links" are one of the latter. On the other hand, term "circuit" is mentioned as "circuit metric/cost", "circuit ID", "circuit database", "circuit type broadcast/p2p", "adjacency" and so on. For example, circuit database can be filled in with "broadcast" and "p2p" circuits, but IS-IS doesn't care whether latter is "p2p" or "p2p over lan". It will use the same procedures for both of them (establishment of adjacency, database synchronization). In other words, I would want to say that term "circuit" is overloaded here - while in 10589 "circuit" means entity of the protocol, in MI-ISIS it means what 10589 calls "subnetwork/link".

Regarding AllIS - yes, some implementations use AllIS only for IIH, and AllL1IS/AllL2IS for SNP/LSP. While it is not beneficial to use AllIS for SNP and LSP PDUs, other implementations behave in this manner, and this is valid behavior.

You have specified that LSP and SNP for standard instance will use AllL1IS/AllL2IS. It is not clear whether AllIS is allowed for MI-capable router for using it in standard instance over P2PoverLAN circuits for SNP and LSP, as it is allowed for non-MI-capable router (per RFC 5309).

Thank you.

---

From: Alia Atlas <[email-masked]>
Date: Fri, 17 Mar 2017 16:50:34 -0400

To clarify further, it is most common for the authors to be retained in a
bis draft.
However, if they are unresponsive (which can cause process problems) or it
causes the author list (which is really more active editors) to grow too
long, then an acknowledgements section is appropriate.

In this case, where there are active authors who were also on RFC 6822, I
assume
that appropriate discussions have happened.

Regards,
Alia

On Fri, Mar 17, 2017 at 4:34 PM, Alia Atlas <[email-masked]> wrote:

> On Fri, Mar 17, 2017 at 4:05 PM, Les Ginsberg (ginsberg) <
> [email-masked]> wrote:
>
>> Uma –
>>
>>
>>
>> The authors of the bis draft are the ones who actively participated in
>> the writing of the bis draft. The fact that some of the authors of RFC 6822
>> did not participate in the writing of the bis draft  in no way diminishes
>> their past contributions which are permanently recorded in RFC 6822.
>>
>>
>>
>> My view is we need not be different here but would be happy to listen
>> from you, AD and other esteemed members of this group.
>>
>>
>>
>> --
>>
>> Uma C.
>>
>>
>>
>> >4) In the IANA considerations, the references should be updated to
>> point to this document, and most particularly if it obsoletes RFC 6822.
>>

---

From: Uma Chunduri <[email-masked]>
Date: Sat, 18 Mar 2017 00:26:15 +0000

Les,

>I am not aware of any requirement to have the original set of authors be authors of a bis document –

                Sorry to know this..

>and there are certainly other examples where authorship has changed.

                Not seen much in other WGs (but you will have numerous examples contrary to this)…

>And there are obvious practical reasons why authorship may change.

                The problem here is - draft currently says it “updates” 6822, but 95% of the content and spirit is same as 6822. In that case, it should have just described the appropriate changes without completely duplicating the same.
                But that was not the case. Now after ADs suggestion, if we agreed to obsolete 6822, it doesn’t sound logical to replace original authors with new set of contributors.

--
Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Sat, 18 Mar 2017 00:29:15 +0000

Hi Alia,

Thx for your response.
In-line [Uma]:
--
Uma C.

From: Alia Atlas [mailto:[email-masked]]
Sent: Friday, March 17, 2017 1:51 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Uma Chunduri <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: AD review of draft-ietf-isis-mi-bis-01

To clarify further, it is most common for the authors to be retained in a bis draft.
[Uma]: This is what I generally see in other WGs..

However, if they are unresponsive (which can cause process problems) or it causes the author list (which is really more active editors) to grow too long, then an acknowledgements section is appropriate.
[Uma]: Possible, but I see your “if” clause..

In this case, where there are active authors who were also on RFC 6822, I assume
that appropriate discussions have happened.
[Uma]: I didn’t remember any discussion on this..

Regards,
Alia

On Fri, Mar 17, 2017 at 4:34 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:
Uma,

Les has already said it.  It is common to have a section that mentions and thanks the authors of the original RFC when a bis version is done with different authors.

Keeping the previous authors can cause issues for reviews and approvals later on.

Regards,
Alia

On Fri, Mar 17, 2017 at 4:05 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Uma –

   Les

From: Uma Chunduri [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, March 17, 2017 11:45 AM

Les,

--
Uma C.

Uma –

   Les

Quick comment:

--
Uma C.

Alia –

[Les:] OK

   Les

Regards,
Alia

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 18 Mar 2017 04:14:39 +0000

Uma –

This was always intended as a replacement for RFC 6822 – it was my error to label it as an update – thanx to Alia for spotting this.

The bis draft does NOT just describe the modifications – it contains the original text of RFC 6822 plus changes – and Appendix A summarizes the changes.

There is no problem here other than I incorrectly labeled this as an update.

   Les

From: Uma Chunduri [mailto:[email-masked]]
Sent: Friday, March 17, 2017 5:26 PM
To: Les Ginsberg (ginsberg); Alia Atlas; [email-masked]; [email-masked]
Subject: RE: AD review of draft-ietf-isis-mi-bis-01

Les,

                Sorry to know this..

--
Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 20 Mar 2017 17:33:19 +0000

Les,

Thx for the clarification.. as I indicated there was no discussion on the mailing list about this and people might have overlooked as the 01 bis draft says it “updates” erroneously.
Have no issues with the updates; but would be good to have some future guidance.
--
Uma C.

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Friday, March 17, 2017 9:15 PM
To: Uma Chunduri <[email-masked]<mailto:[email-masked]>>; Alia Atlas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: AD review of draft-ietf-isis-mi-bis-01

Uma –

   Les

Les,

                Sorry to know this..

--
Uma C.