If some folks think that there needs to be a correction or addition to the architecture, the best thing to do would be to write a new draft and post it for discussion.

This appears to be a substantive technical issue, which is not appropriate for an erratum.  It also doesn't seem appropriate for the IGP drafts.

On 2/13/2018 4:03 AM, Peter Psenak wrote:
Hi Folks,

can we add an errata to RFC 8279, instead of adding the text to both IGP drafts that does not really belong there.


thanks,
Peter

On 13/02/18 08:16 , Tony Przygienda wrote:
+1 what Les says as my understanding of the problem we're tackling here ...

--- tony

On Mon, Feb 12, 2018 at 2:06 PM, Les Ginsberg (ginsberg)
<ginsb...@cisco.com <mailto:ginsb...@cisco.com>> wrote:

    Ice –____

    __ __

    MY understanding is that – in the future – there may be additional
    encaps defined for BIER. When that happens, a given BFR may support
    multiple encaps. In such a case, it is OK if other BFRs supporting
    the same <MT,SD> only support one of the set of encaps – so long as
    we have one encap in common we can successfully forward. I believe
    that is the case the text change is trying to address – not encap vs
    no encap. The original text would have required identical sets of
    encaps to be supported by all BFRs for a give <MT,SD> - which is
    unnecessarily restrictive.____

    __ __

    Make sense?____

    __ __

       Les____

    __ __

    __ __

    *From:*IJsbrand Wijnands (iwijnand)
    *Sent:* Monday, February 12, 2018 1:50 PM


    *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com
    <mailto:ginsb...@cisco.com>>
    *Cc:* Acee Lindem (acee) <a...@cisco.com <mailto:a...@cisco.com>>;
    b...@ietf.org <mailto:b...@ietf.org>; Peter Psenak (ppsenak)
    <ppse...@cisco.com <mailto:ppse...@cisco.com>>; isis-wg@ietf.org
    <mailto:isis-wg@ietf.org> list <isis-wg@ietf.org
    <mailto:isis-wg@ietf.org>>
    *Subject:* Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04____

    __ __

    Les,____

    __ __

        (If MPLS encapsulation (Section 2.1 of [MPLS_BIER_ENCAPS]) is
               being used, this means that every BFR that is advertising
        a label
               for sub-domain S is advertising a label for the
        combination of
               sub-domain S and Disposition BitStringLength L.)____

    __ __

    It says, if MPLS encapsulation is used, there is a Label for the
    {SD, BSL}. So, if there is non-MPLS (ether) only, there will not be
    a Label and the compatibility check will fail. Is that not the same
    a router that does not support MPLS BIER, and treated as a non-BIER
    router?____

    __ __

        [Les:] I don’t see how this text can be used to mean “multiple
        encap types can be supported on the same BFR for a given <MT,SD>”.
        ???____

    __ __

    Are these not like ships in the night? Like an Prefix can be
    reachable over MPLS and IP on the same interface? I do assume you
    want to stay with the encapsulation that you where provisioned in
    and not move from MPLS into non-MPLS. Why do you need to say you can
    support both?____

    __ __

    Thx,____

    __ __

    Ice.____

    __ __

    __ __

        On 12 Feb 2018, at 22:16, Les Ginsberg (ginsberg)
        <ginsb...@cisco.com <mailto:ginsb...@cisco.com>> wrote:

        Ice -

        From: IJsbrand Wijnands (iwijnand)
        Sent: Monday, February 12, 2018 12:58 PM
        To: Les Ginsberg (ginsberg) <ginsb...@cisco.com
        <mailto:ginsb...@cisco.com>>
        Cc: Acee Lindem (acee) <a...@cisco.com <mailto:a...@cisco.com>>;
        b...@ietf.org <mailto:b...@ietf.org>; Peter Psenak (ppsenak)
        <ppse...@cisco.com <mailto:ppse...@cisco.com>>; isis-wg@ietf.org
        <mailto:isis-wg@ietf.org> list <isis-wg@ietf.org
        <mailto:isis-wg@ietf.org>>
        Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04

        Les,


        Perhaps the thread is too long and you have gotten confused. J

        Maybe :-), but...


        The point being discussed now is support for multiple
        encapsulation types (BSL conversion was mentioned in the thread
        – but it is NOT the subject being discussed at the moment).

        I got that, it was removed after a long debate sometime back.



        In latest IS-IS BIER draft we changed:

             >     All routers in the flooding scope of the BIER TLVs
        MUST advertise the
             >     same encapsulation for a given <MT,SD>.  A router
        discovering
             >     encapsulation advertised that is different from its
        own MUST report a
             >     misconfiguration of a specific <MT,SD>.  All received
        BIER
             >     advertisements associated with the conflicting <MT,
        SD> pair MUST be
             >     ignored.
             >
             > "
             >
             > to
             >
             > "
             >
             >     Multiple encapsulations MAY be advertised/supported
        for a given
             >     <MT,SD>.  Clearly, however, there MUST be at least
        one encapsulation
             >     type in common in order for a BIER encapsulated
        packet to be
             >     successfully forwarded between two BFRs.
             >

        Point has been made that this really belongs in the architecture
        RFC, but since it isn’t there it may make sense for the IGP
        drafts to mention it.

        Below is taken from "6.10.1.  BitStringLength Compatibility
        Check” RFC 8279, does this not cover it?

        ****
        The combination of sub-domain S and Imposition BitStringLength L
            passes the BitStringLength Compatibility Check if and only
        if the
            following condition holds:

               Every BFR that has advertised its membership in
        sub-domain S has
               also advertised that it is using Disposition
        BitStringLength L
               (and possibly other BitStringLengths as well) in that
        sub-domain.
               (If MPLS encapsulation (Section 2.1 of [MPLS_BIER_ENCAPS]) is
               being used, this means that every BFR that is advertising
        a label
               for sub-domain S is advertising a label for the
        combination of
               sub-domain S and Disposition BitStringLength L.)

        If a BFIR has been provisioned to use a particular Imposition
            BitStringLength and a particular sub-domain for some set of
        packets,
            and if that combination of Imposition BitStringLength and
        sub-domain
            does not pass the BitStringLength Compatibility Check, the BFIR
            SHOULD log this fact as an error.
        ****

        [Les:] I don’t see how this text can be used to mean “multiple
        encap types can be supported on the same BFR for a given <MT,SD>”.
        ???

            Les


        Thx,

        Ice.



        In the case of IS-IS, because earlier versions of the draft had
        an explicit statement which we now consider too limiting, it
        made sense to make an explicit statement of the more flexible
        behavior.

        In the case of OSPF, the overly restrictive text was never
        present, so it is more debatable as to whether the clarifying
        statement is needed – but doing so keeps the drafts in sync.

        Still, the “right solution” would be to have the statement in
        RFC 8279 – but a bit late for that.

            Les


        From: IJsbrand Wijnands (iwijnand)
        Sent: Monday, February 12, 2018 12:05 PM
        To: Acee Lindem (acee) <a...@cisco.com <mailto:a...@cisco.com>>
        Cc: Tony Przygienda <tonysi...@gmail.com
        <mailto:tonysi...@gmail.com>>; Les Ginsberg (ginsberg)
        <ginsb...@cisco.com <mailto:ginsb...@cisco.com>>; b...@ietf.org
        <mailto:b...@ietf.org>; isis-wg@ietf.org
        <mailto:isis-wg@ietf.org> list <isis-wg@ietf.org
        <mailto:isis-wg@ietf.org>>; Peter Psenak (ppsenak)
        <ppse...@cisco.com <mailto:ppse...@cisco.com>>
        Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04

        Folks,

        I would say its wrong to try and fix the BIER architecture by
        adding this into the IGP drafts. The IGP is a pass-through for
        the BIER information, and adding this text seems to imply that
        the IGP now needs to become BIER aware in order to detect and
        trigger notifications of encapsulation incompatibilities.

        The BIER architecture RFC 8279 has section 6.10 "Use of
        Different BitStringLengths within a Domain”, what is missing in
        that section that would justify the IGP to become aware of
        BitStringLength differences? IMO everything is covered.

        Thx,

        Ice.


        On 12 Feb 2018, at 19:33, Acee Lindem (acee) <a...@cisco.com
        <mailto:a...@cisco.com>> wrote:

        Hi Tony,
        I agree that since architecture has been published, it would not
        hurt to add the 5.2 text to the IGP documents.
        Thanks,
        Acee

        From: Tony Przygienda <tonysi...@gmail.com
        <mailto:tonysi...@gmail.com>>
        Date: Monday, February 12, 2018 at 12:13 PM
        To: Acee Lindem <a...@cisco.com <mailto:a...@cisco.com>>
        Cc: "Peter Psenak (ppsenak)" <ppse...@cisco.com
        <mailto:ppse...@cisco.com>>, "Les Ginsberg (ginsberg)"
        <ginsb...@cisco.com <mailto:ginsb...@cisco.com>>, "b...@ietf.org
        <mailto:b...@ietf.org>" <b...@ietf.org <mailto:b...@ietf.org>>,
        "isis-wg@ietf.org list <mailto:isis-wg@ietf.org%20list>"
        <isis-wg@ietf.org <mailto:isis-wg@ietf.org>>
        Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04

        Peter, Acee, agree that this was missed in architecture and we
        should have talked about multiple encaps on a link there (just
        like we mentioned the BSL conversion). Alas, it was theoretical
        then and we missed. It was just a suggestion here to put it into
        IGP draft as we did in ISIS. I'm fine whichever way you guys
        feel it's better and a clarification draft can be always
        published later after more experience in the field albeit it
        seems that the issue is straight fwd' for most old hands, it's a
        link local decision so just use any matching encaps to transfer,
        however the computation has to agree to prevent blackholes  ...

        Otherwise went through the important sections on -11 and looks
        good to me, no further comments. Thanks for the work

        --- tony

        On Mon, Feb 12, 2018 at 7:58 AM, Acee Lindem (acee)
        <a...@cisco.com <mailto:a...@cisco.com>> wrote:
        With respect to the text in section 5.2, I agree with Peter.

        Thanks
        Acee

        On 2/12/18, 9:59 AM, "BIER on behalf of Peter Psenak (ppsenak)"
        <bier-boun...@ietf.org on behalf of ppse...@cisco.com
<mailto:bier-boun...@ietf.org%20on%20behalf%20of%c2%a0ppse...@cisco.com>>
        wrote:

             Hi Tony,

             OSPF does not have the original text, so it does not need
        the new one.

             IMHO, the text in section 5 of ISIS BIER draft suits better
        to the BIER
             architecture draft than to the IGP extension draft.

             thanks,
             Peter


             On 09/02/18 20:17 , Tony Przygienda wrote:
             > Sure ;-)  let me ping Peter @ the bottom then ... I don't
        think any of
             > the stuff applies to OSPF (was ISIS nits) except we can
        consider an
             > encaps paragraph. We basically suggest both to replace in
        ISIS the
             > encaps section like this
             >
             > before:
             >
             > "
             >     All routers in the flooding scope of the BIER TLVs
        MUST advertise the
             >     same encapsulation for a given <MT,SD>.  A router
        discovering
             >     encapsulation advertised that is different from its
        own MUST report a
             >     misconfiguration of a specific <MT,SD>.  All received
        BIER
             >     advertisements associated with the conflicting <MT,
        SD> pair MUST be
             >     ignored.
             >
             > "
             >
             > now
             >
             > "
             >
             >     Multiple encapsulations MAY be advertised/supported
        for a given
             >     <MT,SD>.  Clearly, however, there MUST be at least
        one encapsulation
             >     type in common in order for a BIER encapsulated
        packet to be
             >     successfully forwarded between two BFRs.
             >
             > "
             >
             > I do think that OSPF would benefit from adding this
        section to clarify
             > the issue which is not theoretical now that we have Ethernet.
             >
             >
             > So Peter, any ETA on outstanding OSPF nits now that we're
        tying up the
             > IETF LC?
             >
             > thanks
             >
             > --- tony
             >
             >
             > On Fri, Feb 9, 2018 at 11:12 AM, Greg Shepherd
        <gjs...@gmail.com
        <mailto:gjs...@gmail.com%0b%C2%A0%20>>
        <mailto:gjs...@gmail.com>> wrote:
             >
             >     No I didn't. Why would I? These are the changes you
        and Les worked
             >     out. I assumed you'd share them as needed. If for
        some reason you're
             >     uncomfortable engaging with the OSPF draft thread and
        authors with
             >     your proposed changes, let me know and I'll broker
        the conversation.
             >
             >     Greg
             >
             >     On Fri, Feb 9, 2018 at 11:04 AM, Tony Przygienda
             >     <tonysi...@gmail.com <mailto:tonysi...@gmail.com
<mailto:tonysi...@gmail.com%20%3cmailto:tonysi...@gmail.com>>>
        wrote:
             >
             >         Les has the diff, I'd expect him to publish any
        minute to the
             >         list ... The encaps was a real defect, the rest
        is just
             >         tightening down the language/spec where it was
        too loose/too
             >         strict.
             >
             >         OSPF still needs update with conversion TLV
        removed, same
             >         paragraph on encaps could be useful. I hope Greg
        pinged Peter ...
             >
             >         thanks
             >
             >         tony
             >
             >         On Fri, Feb 9, 2018 at 10:58 AM, Alia Atlas
        <akat...@gmail.com
        <mailto:akat...@gmail.com%0b%C2%A0%20>>
        <mailto:akat...@gmail.com>> wrote:
             >
             >             On Fri, Feb 9, 2018 at 12:46 PM, Tony Przygienda
             >             <tonysi...@gmail.com
        <mailto:tonysi...@gmail.com
<mailto:tonysi...@gmail.com%20%3cmailto:tonysi...@gmail.com>>>
        wrote:
             >
             >                 Went last nits with Les, we found one
        issue (encaps
             >                 section was wrong, need to look @ OSPF as
        well) and
             >                 basically tightened language in few places.
             >
             >
             >             K - please get that  out with the details of
        changes to the
             >             list.  I did my AD review back in Oct and
        looked at the
             >             differences before issuing
             >             IETF Last Call.
             >
             >             I look forward to reviewing the minor changes.
             >
             >             Regards,
             >             Alia
             >
             >                 tony
             >
             >                 On Tue, Feb 6, 2018 at 3:45 PM, Greg Shepherd
             >                 <gjs...@gmail.com
        <mailto:gjs...@gmail.com
<mailto:gjs...@gmail.com%20%3cmailto:gjs...@gmail.com>>> wrote:
             >
             >                     Thanks Les.
             >
             >                     Any other feedback? Looks like the
        concerns have
             >                     been addressed. Speak now.
             >
             >                     Cheers,
             >                     Greg
             >
             >                     On Thu, Feb 1, 2018 at 7:26 AM, Les
        Ginsberg
             >                     (ginsberg) <ginsb...@cisco.com
        <mailto:ginsb...@cisco.com%0b%C2%A0%20>>
        <mailto:ginsb...@cisco.com>> wrote:
             >
             >                         Greg –____
             >
             >                         __ __
             >
             >                         This thread is outdated.____
             >
             >                         In V6 of the draft we removed the
        restriction to
             >                         limit IS-IS BIER support to area
        boundaries – so
             >                         Toerless’s comment (and my
        proposed text) are no
             >                         longer relevant.____
             >
             >                         __ __
             >
             >                         Specifically:____
             >
             >                         __ __
             >
             >                         Section 4.1:____
             >
             >                         __ __
             >
             >                         “At present, IS-IS support for a
        given BIER
             >                         domain/sub-domain is ____
             >
             > limited to a
        single area -
             >                         or to the IS-IS L2 sub-domain.”____
             >
             >                         __ __
             >
             >                         The above text was removed.____
             >
             >                         __ __
             >
             >                         Section 4.2____
             >
             >                         __ __
             >
             >                         o  BIER sub-TLVs MUST NOT be
        included when a
             >                         prefix reachability____
             >
             >                                advertisement is leaked
        between levels.____
             >
             >                         __ __
             >
             >                         Was changed to____
             >
             >                         __ __
             >
             >                         o  BIER sub-TLVs MUST be included
        when a prefix
             >                         reachability____
             >
             >                                advertisement is leaked
        between levels.____
             >
             >                         __ __
             >
             >                         This aligns IS-IS and OSPF drafts
        in this
             >                         regard.____
             >
             >                         __ __
             >
             >                              Les____
             >
             >                         __ __
             >
             >                         *From:*Greg Shepherd
        [mailto:gjs...@gmail.com
             > <mailto:gjs...@gmail.com>
<mailto:gjs...@gmail.com%0b%C2%A0%20%C2%A0%20%3e%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%3cmailto:gjs...@gmail.com%3e>]
             >                         *Sent:* Thursday, February 01,
        2018 2:23 AM
             >                         *To:* Toerless Eckert <t...@cs.fau.de
        <mailto:t...@cs.fau.de%0b%C2%A0%20>>
        <mailto:t...@cs.fau.de>>
             >                         *Cc:* Les Ginsberg (ginsberg)
             >                         <ginsb...@cisco.com
        <mailto:ginsb...@cisco.com%0b%C2%A0%20>>
        <mailto:ginsb...@cisco.com>>; Tony Przygienda
             > <tonysi...@gmail.com
        <mailto:tonysi...@gmail.com%0b%C2%A0%20>>
           <mailto:tonysi...@gmail.com>>; Hannes Gredler
             >                         (han...@gredler.at
        <mailto:han...@gredler.at> <mailto:han...@gredler.at
        <mailto:han...@gredler.at>>)
             >                         <han...@gredler.at
        <mailto:han...@gredler.at
<mailto:han...@gredler.at%20%3cmailto:han...@gredler.at>>>;
             > b...@ietf.org
        <mailto:b...@ietf.org> <mailto:b...@ietf.org
        <mailto:b...@ietf.org>>;
             > isis-wg@ietf.org
        <mailto:isis-wg@ietf.org> <mailto:isis-wg@ietf.org
        <mailto:isis-wg@ietf.org>> list
             >                         <isis-wg@ietf.org
        <mailto:isis-wg@ietf.org
<mailto:isis-wg@ietf.org%20%3cmailto:isis-wg@ietf.org>>>;
             >                         Christian Hopps <cho...@chopps.org
        <mailto:cho...@chopps.org%0b%C2%A0%20>>
        <mailto:cho...@chopps.org>>
             >
             >
             >                         *Subject:* Re: [Bier] WGLC:
             >
        draft-ietf-bier-isis-extensions-04____
             >
             >                         __ __
             >
             >                         Have these changes been reflected
        in the draft?
             >                         We're in WGLC but this discussion
        needs to come
             >                         to a conclusion so we can
        progress. ____
             >
             >                         __ __
             >
             >                         Greg____
             >
             >                         __ __
             >
             >                         On Tue, Jul 25, 2017 at 12:52 PM,
        Toerless
             >                         Eckert <t...@cs.fau.de
        <mailto:t...@cs.fau.de
<mailto:t...@cs.fau.de%20%3cmailto:t...@cs.fau.de>>>
             >                         wrote:____
             >
             >                             Thanks, Less, that would be
        lovely!
             >
             >                             I didn't check the OSPF
        draft, if its
             >                             similar state, explanatory
        text wold equally
             >                             be appreciated.____
             >
             >
             >                             On Sun, Jul 23, 2017 at
        11:28:08PM +0000,
             >                             Les Ginsberg (ginsberg) wrote:
             >                              > Toerless -
             >                              >
             >                              > I am thinking to add a
        statement in
             >                             Section 4.1 - something like:
             >                              >
             >                              > "At present, IS-IS support
        for a given
             >                             BIER domain/sub-domain is
        limited to a
             >                             single area - or to the IS-IS
        L2 sub-domain."
             >                              >
             >                              > If you believe this would
        be helpful I
             >                             will spin a new version
        (subject to
             >                             review/agreement from my
        co-authors).
             >                              >
             >                              >    Les
             >                              >
             >                              >
             >                              > > -----Original Message-----
             >                              > > From: Toerless Eckert
             > [mailto:t...@cs.fau.de
        <mailto:t...@cs.fau.de>
<mailto:t...@cs.fau.de%20%3cmailto:t...@cs.fau.de%3e>]
             >                              > > Sent: Saturday, July 22,
        2017 6:34 AM
             >                              > > To: Les Ginsberg (ginsberg)
             >                              > > Cc: Tony Przygienda;
        Hannes Gredler
             >                             (han...@gredler.at
        <mailto:han...@gredler.at>
             > <mailto:han...@gredler.at>);
        Greg Shepherd;
             >                              > > b...@ietf.org
        <mailto:b...@ietf.org> <mailto:b...@ietf.org
        <mailto:b...@ietf.org>>;
             > isis-wg@ietf.org
        <mailto:isis-wg@ietf.org> <mailto:isis-wg@ietf.org
        <mailto:isis-wg@ietf.org>>
             >                             list; Christian Hopps
             >                              > > Subject: Re: [Bier] WGLC:
             >
        draft-ietf-bier-isis-extensions-04
             >                              > >
             >                              > > Thanks Les
             >                              > >
             >                              > > When searching various
        terms in the doc
             >                             to figure out what happens i
        am not
             >                              > > sure why i missed this one.
             >                              > >
             >                              > > But: IMHO, RFCs can not
        only be the
             >                             minimum number of words to get a
             >                              > > running implementation.
        It also needs
             >                             to specify what this
        implementation
             >                              > > intends to achieve.
        Otherwise its not
             >                             possible to do a useful review:
             >                              > > The reviewer can to
        verify whether the
             >                             spec will achieve what it
        claims to
             >                              > > achieve is there no
        definitionn of what
             >                             it claims to achieve.
             >                              > >
             >                              > > If i understand ISIS
        correctly, my
             >                             reverse engineering of the
        intent is:
             >                              > >
             >                              > > - BIER TLVs stay within
        single ISIS
             >                             areas. BFIR and BFER must
        therefore be
             >                              > >   in the same ISIS area:
        There is no
             >                             inter-area BIER traffic possible
             >                              > >   with this
        specification. This is also
             >                             true for ISIS area 0.
             >                              > >
             >                              > > - The same BIER
        sub-domain identifiers
             >                             can be re-used
             >                              > > across different ISIS
        areas without
             >                             any current impact. If these
        BFR-IDs
             >                              > >   are non-overlapping,
        then this would
             >                             allow in the future to create
        a single
             >                              > >   cross ISIS area BIER
        sub-domain by
             >                             leaking TLVs for such a BIER
        sub-domain
             >                              > > across ISIS levels.
        Leakage is
             >                             outside the scope of this
        specificication.
             >                              > >
             >                              > > I actually even would
        like to do the
             >                             following:
             >                              > >
             >                              > > - If BIER sub-domains
        are made to span
             >                             multiple ISIS areas and BFR-ids
             >                              > > assignemtns
             >                              > >   are made such that all
        BFR-ids with
             >                             the same SI are in the same
        ISIS ara,
             >                              > >   then it should be in
        the future
             >                             reasonably easy to create
        inter-area BIER
             >                              > >   not by leaking of the
        BIER TLV but by
             >                             having BFIR MPLS unicastBIER
        packets
             >                              > >   for different SIs to
        an appropriate
             >                             L2L1 BFIR that is part of the
        destination
             >                              > > area/SI.
             >                              > >   (if you would use SI
        number that are
             >                             the same as ISIS area numbers
        then
             >                              > >    you could probably do
        this without
             >                             any new signaling. Not quite
        sure if
             >                              > >    you can today easily
        find L1L2
             >                             border router for another
        area via existing
             >                              > > TLVs).
             >                              > >
             >                              > >   Alas, this idea will
        probably be
             >                             killed because of the BIER
        architecture
             >                              > > intent not to engineer
        SI assignments
             >                             in geographical fashions to
             >                              > > minimize traffic
        duplication in the
             >                             presence of multiple SIs.
             >                              > >
             >                              > > Cheers
             >                              > > Toerless
             >                              > >
             >                              > > On Sat, Jul 22, 2017 at
        06:03:53AM
             >                             +0000, Les Ginsberg
        (ginsberg) wrote:
             >                              > > > Tony/Toerless ???
             >                              > > >
             >                              > > > There is an explicit
        statement as to
             >                             scope:
             >                              > > >
             >                              > > > <snip>
             >                              > > > Section 4.2
             >                              > > > ???
             >                              > > > o  BIER sub-TLVs
        MUST NOT be
             >                             included when a prefix
        reachability
             >                              > > >       advertisement is
        leaked between
             >                             levels.
             >                              > > > <end snip>
             >                              > > >
             >                              > > > Tony seems to have
        forgotten that we
             >                             had a discussion about how BIER
             >                              > > might be supported
        across areas and the
             >                             conclusion was we did not know
             >                              > > how to do that yet.
             >                              > > > (Sorry Tony)
             >                              > > >
             >                              > > > Note this is
        ???consistent??? with
             > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2Dbier-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=FwRdfGyEveb9AfmKOlsQTa_M6f7RT2N02wLc96QcFmI&e=
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2Dbier-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=FwRdfGyEveb9AfmKOlsQTa_M6f7RT2N02wLc96QcFmI&e=>
             >
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2Dbier-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=FwRdfGyEveb9AfmKOlsQTa_M6f7RT2N02wLc96QcFmI&e=
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2Dbier-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=FwRdfGyEveb9AfmKOlsQTa_M6f7RT2N02wLc96QcFmI&e=>>
             >                              > >
        ospf-bier-extensions-07.txt Section
             >
2.5<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=gzwy_n3ZN-lRwF4Ou6NVHEAarhQF22bRElJ6kiqHbqo&e=
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2D-250b-25C2-25A0-2520&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=WUyeExz9aM6aWI40OfobGvQ-Sr1x4kuhMECczm1lBJg&e=>>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=gzwy_n3ZN-lRwF4Ou6NVHEAarhQF22bRElJ6kiqHbqo&e=
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=gzwy_n3ZN-lRwF4Ou6NVHEAarhQF22bRElJ6kiqHbqo&e=>>
             >                              > >
             >
        bier-ospf-bier-extensions-07.txt%20Section%202.5>
             >                             - which limits the
             >                              > > flooding scope of BIER
        information to a
             >                             single area unless it can be
        validated
             >                              > > that the best path to
        the prefix with
             >                             BIER info can be validated to
        be to a
             >                              > > router which itself
        advertised the BIER
             >                             info. This is not something
        IS-IS can do
             >                              > > since a single IS-IS
        instance only
             >                             supports one area and
        therefore does not
             >                              > > have the Level-1
        advertisements of the
             >                             originating router when that
        router is
             >                              > > in another area.
             >                              > > >
             >                              > > > A few more responses
        inline.
             >                              > > >
             >                              > > > From: BIER
             > [mailto:bier-boun...@ietf.org
             >
        <mailto:bier-boun...@ietf.org>
<mailto:bier-boun...@ietf.org%0b%C2%A0%20%C2%A0%20%3e%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%3cmailto:bier-boun...@ietf.org%3e>]
        On Behalf Of
             >                             Tony Przygienda
             >                              > > > Sent: Friday, July 21,
        2017 5:17 AM
             >                              > > > To: Toerless Eckert
             >                              > > > Cc: Hannes Gredler
        (han...@gredler.at <mailto:han...@gredler.at>
             > <mailto:han...@gredler.at>);
        Greg Shepherd;
             > b...@ietf.org
        <mailto:b...@ietf.org> <mailto:b...@ietf.org
        <mailto:b...@ietf.org>>;
             >                              > > > isis-wg@ietf.org
        <mailto:isis-wg@ietf.org>
             > <mailto:isis-wg@ietf.org>
        list; Christian Hopps
             >                              > > > Subject: Re: [Bier] WGLC:
             >
        draft-ietf-bier-isis-extensions-04
             >                              > > >
             >                              > > > Terminology is a bit
        nits  IMO since
             >                             the doc is reading clear
        enough for
             >                              > > someone who read BIER &
        ISIS. I can
             >                             reread it or Les can comment
        whether
             >                              > > we should tighten
        glossary ...
             >                              > > >
             >                              > > > With the scope I
        agree, that got lost
             >                             and the doc should be
        possibly rev'ed
             >                              > > before closing LC. Yes,
        we flood AD
             >                             wide was the agreement but
        something
             >                              > > mentioning that this
        could change in
             >                             the future is good so we are
        forced to
             >                              > > give it some thought how
        that would
             >                             transition ...
             >                              > > >
             >                              > > > Thinking further
        though, in ISIS we
             >                             have a clean document really.
        The  BIER
             >                              > > sub-TLVs go into well
        defined TLVs in
             >                             terms of flooding scope.
        Normal L1-L2
             >                              > > redistribution can be
        used to get the
             >                             info to all needed places
        AFAIS. So
             >                              > > maybe nothing needs to
        be written. I
             >                             wait for Les to chime in.
             >                              > > >
             >                              > > > OSPF I would have to
        look @ scopes
             >                             again & think whether we need to
             >                              > > write something or maybe
        Peter can
             >                             comment ...
             >                              > > >
             >                              > > > --- tony
             >                              > > >
             >                              > > >
             >                              > > >
             >                              > > > On Fri, Jul 21, 2017
        at 8:27 AM,
             >                             Toerless Eckert
             >                              > > <t...@cs.fau.de
        <mailto:t...@cs.fau.de%0b%C2%A0%20>>
        <mailto:t...@cs.fau.de><mailto:t...@cs.fau.de
        <mailto:t...@cs.fau.de%0b%C2%A0%20>>
        <mailto:t...@cs.fau.de>>> wrote:
             >                              > > > Sorry, past the two
        weeks, but
             >                             hopefully  benign textual
        comments:
             >                              > > >
             >                              > > > We tried to find an
        explicit
             >                             statement about the scope of
        BIER TLVs - eg:
             >                              > > > are they meant to stay
        within an
             >                             area, have some
        redistribution across
             >                              > > > areas/levels or not.
             >                              > > >
             >                              > > > Tony said WG agreement
        was to have
             >                             these TLV be flooded across the
             >                              > > > whole ISIS domain for
        now (this
             >                             draft). So an explicit
        statement to that
             >                              > > effect would
             >                              > > > be great (All BIER
        sub-domains TLVs
             >                             are flooded across all ISIS
        areas/levels,
             >                              > > so they span the whole
        ISIS domain).
             >                              > > >
             >                              > > > Also, if future work
        may/should could
             >                             improve on that maybe some
             >                              > > > sentence about that (i
        guess one
             >                             could just have ISIS
        intra-area BIER sub-
             >                              > > domains ?).
             >                              > > >
             >                              > > > Also: Do a check about
        possible
             >                             ambiguity of any generic
        terms like
             >                              > > sub-domain, level, area,
        topology so
             >                             that reader that don't know the
             >                              > > terminology ofall
        protocols (ISIS,
             >                             BIER) by heart can easily
        know which
             >                              > > protocol is referred to.
             >                              > > >
             >                              > > > [Les:] There is no
        mention of
             >                             ???level??? in the document.
             >                              > > > The use of
        ???sub-domain??? is
             >                             clearly always associated
        with ???BIER???.
             >                              > > > ???topology??? is
        always used as an
             >                             RFC 5120 topology ??? therefore              >                              > > clearly an IS-IS topology.
             >                              > > > There is only one use
        of the term
             >                             ???area??? (in Section 5.1).
        That text
             >                              > > might deserve a bit of
        clarification
             >                             given this might be either a
        Level 1 area or
             >                              > > the Level2 sub-domain.
        I???ll take a
             >                             pass at it.
             >                              > > > (BTW ??? I am talking
        about IS-IS
             >                             area/L2sub-domain Toerless. ???)
             >                              > > >
             >                              > > > I don???t see that any
        other
             >                             clarification is needed ???
        but Toerless ??? if
             >                              > > you can point to any
        specific
             > sentences/paragraphs which
        you find confusing
             >                              > > - I???ll take a second look.
             >                              > > >
             >                              > > > Les
             >                              > > >
             >                              > > >
             >                              > > > I guess there are no
        BIER level, area
             >                             or topologies, but still makes
             >                              > > > reading easier if the
        doc would say
             >                             "ISIS level", "ISIS area", or at
             >                              > > > least have them in the
        Terminology
             >                             section. And probably in
             >                              > > > terminology say
        "domain -> in the
             >                             context of this document the BIER
             >                              > > domain which is also the
        same as the
             >                             ISIS domain"
             >                              > > > (which i hope is the
        correct
             >                             statement, see above).
             >                              > > >
             >                              > > > Cheers
             >                              > > >     Toerless
             >                              > > >
             >                              > > >
             >
        _______________________________________________
             >                              > > > BIER mailing list
             >                              > > > b...@ietf.org
        <mailto:b...@ietf.org>
             >
        <mailto:b...@ietf.org><mailto:b...@ietf.org
        <mailto:b...@ietf.org%0b%C2%A0%20>>
        <mailto:b...@ietf.org>>
             >                              > > >
             > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>
             >
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>>
             >                              > > >
             >                              > > >
             >                              > > >
             >                              > > > --
             >                              > > > We???ve heard that a
        million monkeys
             >                             at a million keyboards could
             >                              > > produce the complete
        works of
             >                             Shakespeare; now, thanks to
        the Internet,
             >                              > > we know that is not true.
             >                              > > > ???Robert Wilensky
             >                              > >
             >                              > > --
             >                              > > ---
             >                              > > t...@cs.fau.de
        <mailto:t...@cs.fau.de> <mailto:t...@cs.fau.de
        <mailto:t...@cs.fau.de>>____
             >
             >                         __ __
             >
             >
             >
             >
             >
        _______________________________________________
             >                 BIER mailing list
             > b...@ietf.org
        <mailto:b...@ietf.org> <mailto:b...@ietf.org <mailto:b...@ietf.org>>              > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>
             >
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>>
             >
             >
             >
             >
             >
             >
             >
             > _______________________________________________
             > BIER mailing list
             > b...@ietf.org <mailto:b...@ietf.org>
             > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>
             >

             _______________________________________________
             BIER mailing list
        b...@ietf.org <mailto:b...@ietf.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>



        _______________________________________________
        BIER mailing list
        b...@ietf.org <mailto:b...@ietf.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>

        <image001.png>

        _______________________________________________
        BIER mailing list
        b...@ietf.org <mailto:b...@ietf.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>

        <image001.png>____

    __ __

    ____

    __ __


    _______________________________________________
    BIER mailing list
    b...@ietf.org <mailto:b...@ietf.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>



_______________________________________________
BIER mailing list
b...@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

Reply via email to