Subject: Re: [Bier] Alvaro Retana's No Objection on draft-ietf-bier-ospf-bier-extensions-14: (with COMMENT)

From: Tony Przygienda <[email-masked]>
Date: Thu, 1 Mar 2018 19:57:58 -0800

ok, I went over it once more, all issues seem addressed adequatly.
Outstanding points I don't think need addressing further

* invalid vs. illegal BFR-id language disparity ospf vs isis signalling.
That's really a defect of RFC8279 where we should have been stricter with
language. Not a problem of IGP drafts
* registry: I think that will be cleaned up during publication process,
i.e. registry created and references taken out of the drafts
* no /32 /128 length restriction in OSPF which IMO is fine given RFC8279 is
not mandating it and OSPF works fine without this restriction. The length
clause would not change any other considerations anyway such as behavior
when 2 routers advertise the same prefix in an area with conflicting BIER
information which is addressed in the draft already.

Alvaro, I issue here a 7 days last WG LC just to have it all following
procedure the way ISIS draft did and then fwd' back to IESG for publication
...

Everyone, this constitutes a 7 days last call limited to changes in
versions -14 and -15

thanks

--- tony

On Fri, Feb 23, 2018 at 6:58 AM, Alvaro Retana <[email-masked]>
wrote:

> Peter:
>
> Hi!  Thanks for addressing my comment!
>
> Alvaro.
>
> On February 23, 2018 at 8:16:49 AM, Peter Psenak ([email-masked])
> wrote:
>
> Hi Alvaro,
>
> please see inline (##PP):
>
> On 23/02/18 00:14 , Alvaro Retana wrote:
> > On February 22, 2018 at 11:57:08 AM, Peter Psenak ([email-masked]
> > <mailto:[email-masked]>) wrote:
> >
> > Peter:
> >
> > Hi!
> >
> >> > ----------------------------------------------------------------------
>
> >> > COMMENT:
> >> > ----------------------------------------------------------------------
>
> >> >
> >> > (1) The specification of the sub-TLVs still needs some work:
> >> >
> >> > - MT-ID: What should a receiver do if the MT-ID is in the 128-255
> range?
> >>
> >> rfc4915 says these are "Invalid and SHOULD be ignored" Do we nee to say
> >> the same here again?
> >
> > Yes. rfc4915 refers specifically to what to do with the value in the
> > LSAs when used for MTR.
> >
> > What does it mean to ignore the MT-ID in the BIER Sub-TLV?
> >
> > For example... "Each BFR sub-domain MUST be associated with one and only
> > one OSPF topology that is identified by the MT-ID." If the MT-ID is not
> > known (because it is ignored), then how can we enforce this check?
>
> ##PP
> ok, I have added the following statement:
>
> "If the MT-ID value is outside of the values specified in [RFC4915], the
> BIER Sub-TLV MUST be ignored."
>
> >
> >
> >> >
> >> > - "BFR-id...If the BFR is not locally configured with a valid BFR-id,
> the value
> >> > of this field is set to invalid BFR-id per [RFC8279]." I looked in
> rfc8279 for
> >> > the text about "invalid BFR-id", but found this instead: "The value 0
> is not a
> >> > legal BFR-id." I assume that in this case "invalid" is the same as
> "not
> >> > legal". It would be nice to be consistent.
> >>
> >> would you agree with:
> >>
> >> "the value of this field is set to 0, which is defined as illegal in
> >> [RFC8279].
> >
> > Yeah, that’s fine.
> >
> > Side comment: it’s a shame that rfc8279 chose “illegal” to describe a
> > value that can be used.
> >
> >
> >> >
> >> > - "When such duplication is detected all BFRs advertising duplicates
> MUST be
> >> > treated as if they did not advertise a valid BFR-id." How are BFRs
> that
> >> > advertise an invalid BFR-id treated?
> >>
> >> what about:
> >>
> >> "as if they did not advertise a legal BFR-id"
> >
> > Sorry…the question is: if the BFD-id is 0, then what? What needs to be
> > done by the receiver?
>
> rfc8279, section 5 says:
>
> " If BFR-A determines that BFR-B and BFR-C have both advertised the
> same BFR-id for the same sub-domain, BFR-A MUST log an error.
> Suppose that the duplicate BFR-id is "N". When BFR-A is
> functioning as a BFIR, it MUST NOT encode the BFR-id value N in
> the BIER encapsulation of any packet that has been assigned to the
> given sub-domain, even if it has determined that the packet needs
> to be received by BFR-B and/or BFR-C.
>
> This will mean that BFR-B and BFR-C cannot receive multicast
> traffic at all in the given sub-domain until the provisioning
> error is fixed. However, that is preferable to having them
> receive each other's traffic.
>
>
> ...
>
> If a BFR advertises that it has a BFR-id of 0 in a particular
> sub-domain, other BFRs receiving the advertisement MUST interpret
> that advertisement as meaning that the advertising BFR does not have
> a BFR-id in that sub-domain."
>
>
> So I rewrote the section as:
>
> "All BFRs MUST detect advertisement of duplicate valid BFR-IDs for a
> given MT-ID and Sub-domain-ID. When such duplication is detected by the
> BFR, it MUST behave as described in section 5 of [RFC8279]."
>
>
> >
> >
> >> >
> >> > - What should a receiver do if the BSL is set to a value not
> supported in
> >> > rfc8296?
> >>
> >> what about:
> >>
> >> "If the BS length is set to a value that does not match any of the
> >> allowed values specified in [RFC8296], the BIER MPLS Encapsulation
> >> Sub-TLV MUST be ignored."
> >
> > ok
> >
> >
> >> >
> >> > - "Label ranges within all BIER MPLS Encapsulation Sub-TLVs
> advertised by the
> >> > same BFR MUST NOT overlap. If the overlap is detected, the
> advertising router
> >> > MUST be treated as if it did not advertise any BIER sub-TLVs." If an
> overlap
> >> > is detected, the result is that *all* BFRs (advertising the overlap)
> are
> >> > treated as if the BIER sub-TLV was not advertised, right? The text is
> not
> >> > clear as to whether the result applies to all or just the BFR that
> advertised
> >> > last (and resulted in the detection happening).
> >>
> >> above paragraph talks about the case where a single BFR advertises the
> >> overlapping label ranges in multiple BIER MPLS Encapsulation Sub-TLVs
> it
> >> advertises.
> >
> > Yeah…sorry…overlooked that first part.
> >
> >
> >> >
> >> > - "All advertised labels MUST be valid..." What is a "valid" label?
> >>
> >> I'm tempted to get rid of the above statement, as we specified earlier
> >> that the label "A 3 octet field, where the 20 rightmost bits represent
> >> the first label" and any value should be fine.
> >
> > Well…there are some reserved values… rfc3032…
> >
>
> How to deal with the reserved labels by BIER should have been defined in
> rfc8296 or rfc8279, not in the IGP extension draft really. I have
> removed the following text:
>
> "All advertised labels MUST be valid, otherwise the BIER sub-TLV MUST be
> ignored.
>
> thanks,
> Peter
>
> >
> > ...
> >
> >> >
> >> > (2) Security Considerations
> >> >
> >> > - I support Eric's DISCUSS. It seems to me that an attacker could
> simply
> >> > advertise duplicate BFR-IDs or overlapping label ranges and have a
> significant
> >> > impact on the network.
> >>
> >> that should be taken care of by protocol authentication and existing
> >> text covers that:
> >>
> >> "There can be deployments where potential attackers have access to one
> >> or more networks in the OSPF routing domain. In these deployments,
> >> stronger authentication mechanisms such as those specified in [RFC7474]
> >> SHOULD be used."
> >
> > I’ll let Eric handle the DISCUSS and whether he thinks this is ok.
> >
> >> >
> >> > (3) IANA Considerations
> >> >
> >> > Section 2.2: "The BIER MPLS Encapsulation Sub-TLV is a Sub-TLV of the
> BIER
> >> > Sub-TLV." However, the type for this sub-sub-TLV is allocated from
> the OSPF
> >> > Extended Prefix sub-TLV registry...and not from a new registry for
> sub-TLVs for
> >> > the BIER Sub-TLV.
> >>
> >> The OSPFv2 Extended Prefix TLV Sub-TLVs registry "defines sub-TLVs
> >> at any level of nesting for OSPFv2 Extended Prefix TLVs".
> >>
> >> We have 16 bits for TLV type in OSPF, so we can afford to do so :)
> >
> > Ah, I see. That text is buried in rfc7684, and not reflected in the
> > registry itself.
> >
> > We’re good then.
> >
> > Thanks!
> >
> > Alvaro.
> >
>
>
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>
>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 2 Mar 2018 14:11:52 +0000

Looking at -15, I see the draft is still called “OSPF Extensions for BIER”. One comment I had in my shepherd write-up is that it should be renamed to ‘OSPFv2 Extensions for BIER’, I didn’t see any discussions on this (except Mirja who agrees with the comment).

From: Tony Przygienda <[email-masked]>
Date: Thursday, March 1, 2018 at 10:58 PM
To: Alvaro Retana <[email-masked]>
Cc: "Peter Psenak (ppsenak)" <[email-masked]>, The IESG <[email-masked]>, "Reshad Rahman (rrahman)" <[email-masked]>, BIER WG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Bier] Alvaro Retana's No Objection on draft-ietf-bier-ospf-bier-extensions-14: (with COMMENT)

ok, I went over it once more, all issues seem addressed adequatly. Outstanding points I don't think need addressing further
* invalid vs. illegal BFR-id language disparity ospf vs isis signalling. That's really a defect of RFC8279 where we should have been stricter with language. Not a problem of IGP drafts
* registry: I think that will be cleaned up during publication process, i.e. registry created and references taken out of the drafts
* no /32 /128 length restriction in OSPF which IMO is fine given RFC8279 is not mandating it and OSPF works fine without this restriction. The length clause would not change any other considerations anyway such as behavior when 2 routers advertise the same prefix in an area with conflicting BIER information which is addressed in the draft already.

Alvaro, I issue here a 7 days last WG LC just to have it all following procedure the way ISIS draft did and then fwd' back to IESG for publication ...
Everyone, this constitutes a 7 days last call limited to changes in versions -14 and -15

thanks
--- tony

On Fri, Feb 23, 2018 at 6:58 AM, Alvaro Retana <[email-masked]<mailto:[email-masked]>> wrote:
Peter:

Alvaro.

On February 23, 2018 at 8:16:49 AM, Peter Psenak ([email-masked]<mailto:[email-masked]>) wrote:
Hi Alvaro,

On 23/02/18 00:14 , Alvaro Retana wrote:
> On February 22, 2018 at 11:57:08 AM, Peter Psenak ([email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>) wrote:
>
> Peter:
>
> Hi!
>
>> > - MT-ID: What should a receiver do if the MT-ID is in the 128-255 range?
>>

##PP

>
>
>> >
>> > - "BFR-id...If the BFR is not locally configured with a valid BFR-id, the value
>> > of this field is set to invalid BFR-id per [RFC8279]." I looked in rfc8279 for
>> > the text about "invalid BFR-id", but found this instead: "The value 0 is not a
>> > legal BFR-id." I assume that in this case "invalid" is the same as "not
>> > - "When such duplication is detected all BFRs advertising duplicates MUST be
>> > treated as if they did not advertise a valid BFR-id." How are BFRs that

rfc8279, section 5 says:

...

>
>
>> >
>> > - What should a receiver do if the BSL is set to a value not supported in
>> > rfc8296?
>>
>> what about:
>>
>> > - "Label ranges within all BIER MPLS Encapsulation Sub-TLVs advertised by the
>> > same BFR MUST NOT overlap. If the overlap is detected, the advertising router
>> > MUST be treated as if it did not advertise any BIER sub-TLVs." If an overlap
>> > is detected, the result is that *all* BFRs (advertising the overlap) are
>> > treated as if the BIER sub-TLV was not advertised, right? The text is not
>> > clear as to whether the result applies to all or just the BFR that advertised
>> overlapping label ranges in multiple BIER MPLS Encapsulation Sub-TLVs it
>> advertises.
>

thanks,
Peter

>> > - I support Eric's DISCUSS. It seems to me that an attacker could simply
>> > advertise duplicate BFR-IDs or overlapping label ranges and have a significant
>> > impact on the network.
>>
>> > Section 2.2: "The BIER MPLS Encapsulation Sub-TLV is a Sub-TLV of the BIER
>> > Sub-TLV." However, the type for this sub-sub-TLV is allocated from the OSPF
>> > Extended Prefix sub-TLV registry...and not from a new registry for sub-TLVs for
>> > the BIER Sub-TLV.
>>

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

---

From: Peter Psenak <[email-masked]>
Date: Fri, 02 Mar 2018 15:25:30 +0100

Reshad,

well, there are way too many RFCs that specifies something OSPFv2 
specific with "OSPF" in a name. I don't think this is a big deal, but I 
can certainly change that as a part of the publication process.

thanks,
Peter

On 02/03/18 15:11 , Reshad Rahman (rrahman) wrote:
> Looking at -15, I see the draft is still called “OSPF Extensions for
> BIER”. One comment I had in my shepherd write-up is that it should be
> renamed to ‘OSPFv2 Extensions for BIER’, I didn’t see any discussions on
> this (except Mirja who agrees with the comment).
>
> *From: *Tony Przygienda <[email-masked]>
> *Date: *Thursday, March 1, 2018 at 10:58 PM
> *To: *Alvaro Retana <[email-masked]>
> *Cc: *"Peter Psenak (ppsenak)" <[email-masked]>, The IESG
> <[email-masked]>, "Reshad Rahman (rrahman)" <[email-masked]>, BIER WG
> <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]"
> <[email-masked]>
> *Subject: *Re: [Bier] Alvaro Retana's No Objection on
> draft-ietf-bier-ospf-bier-extensions-14: (with COMMENT)
>
> That's really a defect of RFC8279 where we should have been stricter
> with language. Not a problem of IGP drafts
>
> * no /32 /128 length restriction in OSPF which IMO is fine given RFC8279
> is not mandating it and OSPF works fine without this restriction. The
> length clause would not change any other considerations anyway such as
> behavior when 2 routers advertise the same prefix in an area with
> conflicting BIER information which is addressed in the draft already.
>
> procedure the way ISIS draft did and then fwd' back to IESG for
> publication ...
>
> On Fri, Feb 23, 2018 at 6:58 AM, Alvaro Retana
> <[email-masked]<mailto:[email-masked]>> wrote:
>
>     Peter:
>
>     On February 23, 2018 at 8:16:49 AM, Peter Psenak
>     ([email-masked]<mailto:[email-masked]>) wrote:
>
>         Hi Alvaro,
>

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 6 Mar 2018 14:17:28 -0800

OK,

draft-ietf-bier-isis-extensions-09
<https://datatracker.ietf.org/doc/draft-ietf-bier-isis-extensions/>

limited last call finished now. I see the document moved to publication.

On OSPF I still see Suresh & Eric in discuss. Peter, did we address those
comments ?

thanks

--- tony

---

From: Alia Atlas <[email-masked]>
Date: Fri, 9 Mar 2018 16:48:25 -0500

Hi Peter,

I do not see discussion with Eric or Suresh on their Discusses.
This draft also has Normative References to RFC 8279 and RFC 8296.

The Discusses need to be resolved.  The normative reference (where the
Status Update
was deferred), means that when this is approved, it'll have to have an RFC
Editor Note to
hold it until that Status Update is approved (or bis versions are issued,
if necessary).

I do not know if resolving of the Discusses will happen by Weds of IETF.
If not, then the
draft will not have a Yes ballot (unless Alvaro changes his) and may need
to go back through
IESG Evaluation.

Regards,
Alia

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 10 Mar 2018 00:56:49 +0000

Hi Alia,
Murphy’s law of draft progression timing, Peter has been on PTO for the last week (skiiing I believe but not positive). I’m sure he will respond shortly.
Thank,
Acee

From: BIER <[email-masked]> on behalf of Alia Atlas <[email-masked]>
Date: Friday, March 9, 2018 at 4:48 PM
To: "Peter Psenak (ppsenak)" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "Reshad Rahman (rrahman)" <[email-masked]>, "[email-masked]" <[email-masked]>, BIER WG <[email-masked]>, The IESG <[email-masked]>, Alvaro Retana <[email-masked]>
Subject: Re: [Bier] Alvaro Retana's No Objection on draft-ietf-bier-ospf-bier-extensions-14: (with COMMENT)

Hi Peter,

The Discusses need to be resolved.  The normative reference (where the Status Update
was deferred), means that when this is approved, it'll have to have an RFC Editor Note to
hold it until that Status Update is approved (or bis versions are issued, if necessary).

I do not know if resolving of the Discusses will happen by Weds of IETF.  If not, then the
draft will not have a Yes ballot (unless Alvaro changes his) and may need to go back through
IESG Evaluation.

Regards,
Alia

On Tue, Mar 6, 2018 at 5:17 PM, Tony Przygienda <[email-masked]<mailto:[email-masked]>> wrote:
OK,

draft-ietf-bier-isis-extensions-09<https://datatracker.ietf.org/doc/draft-ietf-bier-isis-extensions/>

limited last call finished now. I see the document moved to publication.
On OSPF I still see Suresh & Eric in discuss. Peter, did we address those comments ?
thanks
--- tony

On Thu, Mar 1, 2018 at 7:57 PM, Tony Przygienda <[email-masked]<mailto:[email-masked]>> wrote:

thanks
--- tony

Alvaro.

##PP

rfc8279, section 5 says:

...

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Mon, 12 Mar 2018 17:41:41 +0100

Hi Alia, Suresh, Eric,

sorry for late response, I was on PTO last week.

Regarding Eric's comment, the securrity section has been updated in 
version 13, which has been published on Feb. 20th. Not sure why it still 
shows as unresolved.

Regarding Suresh's comments:

Section 2.2 BIER MPLS Encapsulation Sub-TLV

This should be straightforward to fix but it is not clear if the label 
range is allowed to wrap around (overflow) or not past the 20 bit space. 
e.g. is a Label=2^20-X with a MSI of X or larger legal? I was hoping 
that RFC8296 would have covered this but unfortunately it leaves it to 
this document (and the IS-IS document) to specify.

==> I have added following sentence:

"If the value of (Label + (Max SI)) is more than 1048575, the BIER MPLS 
Encapsulation Sub-TLV MUST be ignored."

Section 2.1. BIER Sub-TLV

- No handling specified for the Reserved field in this sub-TLV. 
Assuming, set to zero and ignore on receipt? Please specify.

===> I have added the section about the reserved field.

- I think there might be an IANA registry required for the "BIER 
Algorithm" to keep track of new algorithms (if any)

==> version 15 already says:

      "BAR: Single octet BIER specific algorithm used to calculate
       underlay paths to reach other BFRs.  Values are allocated from the
       "BIER Algorithm Registry" which is defined in
       [I-D.ietf-bier-isis-extensions]."

- typo: s/BRF/BFR/

==> fixed

* Section 2.2 BIER MPLS Encapsulation Sub-TLV

"Max SI : A 1 octet field encoding the Maximum Set Identifier (section 1 
of [RFC8296])"

There is no definition for "Maximum Set Identifier" in RFC8296. Did you 
just mean "Set Identifier"? If not, can you clarify what you mean?

==> RFC8296 defines "Set Identifier". We are advertising the maximum 
value for the "Segment Identifier" for the for the BIER sub-domain. In 
other words we are advertising the number of "Set Identifier" used in 
BIER sub-domain.

If you all agree, I can update the drat as above and publish next Monday.

thanks,
Peter

On 09/03/18 22:48 , Alia Atlas wrote:
>         ok, I went over it once more, all issues seem addressed
>         adequatly. Outstanding points I don't think need addressing further
>
>         * invalid vs. illegal BFR-id language disparity ospf vs isis
>         signalling. That's really a defect of RFC8279 where we should
>         have been stricter with language. Not a problem of IGP drafts
>         * registry: I think that will be cleaned up during publication
>         process, i.e. registry created and references taken out of the
>         drafts
>         * no /32 /128 length restriction in OSPF which IMO is fine given
>         RFC8279 is not mandating it and OSPF works fine without this
>         restriction. The length clause would not change any other
>         considerations anyway such as behavior when 2 routers advertise
>         the same prefix in an area with conflicting BIER information
>         which is addressed in the draft already.
>
>         Alvaro, I issue here a 7 days last WG LC just to have it all
>         following procedure the way ISIS draft did and then fwd' back to
>         IESG for publication ...
>
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>             Peter:
>
>             ([email-masked] <mailto:[email-masked]>) wrote:
>
>>             Hi Alvaro,
>>
>>             > On February 22, 2018 at 11:57:08 AM, Peter Psenak ([email-masked] <mailto:[email-masked]>
>>             > <mailto:[email-masked] <mailto:[email-masked]>>) wrote:
>>             >
>>             > Peter:
>>             >
>>             > Hi!
>>             >
>             [email-masked] <mailto:[email-masked]>
>             <https://www.ietf.org/mailman/listinfo/bier>
>
>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/bier>
>
>

---

From: Peter Psenak <[email-masked]>
Date: Mon, 12 Mar 2018 17:49:46 +0100

Resending with correct Suresh's address.

Hi Alia, Suresh, Eric,

- typo: s/BRF/BFR/

==> fixed

thanks,
Peter

On 10/03/18 01:56 , Acee Lindem (acee) wrote:
> Hi Alia,
>
> Murphy’s law of draft progression timing, Peter has been on PTO for the
> last week (skiiing I believe but not positive). I’m sure he will respond
> shortly.
>
> Thank,
>
> Acee
>
> *From: *BIER <[email-masked]> on behalf of Alia Atlas
> <[email-masked]>
> *Date: *Friday, March 9, 2018 at 4:48 PM
> *To: *"Peter Psenak (ppsenak)" <[email-masked]>,
> "[email-masked]" <[email-masked]>
> *Cc: *"Reshad Rahman (rrahman)" <[email-masked]>,
> "[email-masked]"
> <[email-masked]>, BIER WG
> <[email-masked]>, The IESG <[email-masked]>, Alvaro Retana
> <[email-masked]>
> On Tue, Mar 6, 2018 at 5:17 PM, Tony Przygienda
> <[email-masked]<mailto:[email-masked]>> wrote:
>
>     OK,
>
>     	
>
>     On Thu, Mar 1, 2018 at 7:57 PM, Tony Przygienda
>     <[email-masked]<mailto:[email-masked]>> wrote:
>

---

From: Alia Atlas <[email-masked]>
Date: Mon, 12 Mar 2018 13:24:57 -0400

Peter,

I'm happy to approve getting this posted before Monday at IETF.
I'd like to get these drafts off to the RFC Editor ASAP.

Thanks,
Alia

On Mon, Mar 12, 2018 at 12:41 PM, Peter Psenak <[email-masked]> wrote:

> e.g. is a Label=2^20-X with a MSI of X or larger legal? I was hoping that
> RFC8296 would have covered this but unfortunately it leaves it to this
> document (and the IS-IS document) to specify.
>
> - No handling specified for the Reserved field in this sub-TLV. Assuming,
> set to zero and ignore on receipt? Please specify.
>
> ==> RFC8296 defines "Set Identifier". We are advertising the maximum value
> for the "Segment Identifier" for the for the BIER sub-domain. In other
> words we are advertising the number of "Set Identifier" used in BIER
> sub-domain.
>
>
>
>
>>>             > On February 22, 2018 at 11:57:08 AM, Peter Psenak (
>>> [email-masked] <mailto:[email-masked]>

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 12 Mar 2018 18:56:02 +0000

Hi Peter,
  All your suggested changes look good to me. I will clear as soon as the new version posts.

Regards
Suresh

On Mar 12, 2018, at 12:49 PM, Peter Psenak <[email-masked]<mailto:[email-masked]>> wrote:

Hi Alia, Suresh, Eric,

Regarding Eric's comment, the securrity section has been updated in version 13, which has been published on Feb. 20th. Not sure why it still shows as unresolved.

This should be straightforward to fix but it is not clear if the label range is allowed to wrap around (overflow) or not past the 20 bit space. e.g. is a Label=2^20-X with a MSI of X or larger legal? I was hoping that RFC8296 would have covered this but unfortunately it leaves it to this document (and the IS-IS document) to specify.

"If the value of (Label + (Max SI)) is more than 1048575, the BIER MPLS Encapsulation Sub-TLV MUST be ignored."

- No handling specified for the Reserved field in this sub-TLV. Assuming, set to zero and ignore on receipt? Please specify.

- I think there might be an IANA registry required for the "BIER Algorithm" to keep track of new algorithms (if any)

- typo: s/BRF/BFR/

==> fixed

"Max SI : A 1 octet field encoding the Maximum Set Identifier (section 1 of [RFC8296])"

There is no definition for "Maximum Set Identifier" in RFC8296. Did you just mean "Set Identifier"? If not, can you clarify what you mean?

==> RFC8296 defines "Set Identifier". We are advertising the maximum value for the "Segment Identifier" for the for the BIER sub-domain. In other words we are advertising the number of "Set Identifier" used in BIER sub-domain.

thanks,
Peter

Thank,

Acee

*From: *BIER <[email-masked]<mailto:[email-masked]>> on behalf of Alia Atlas
<[email-masked]<mailto:[email-masked]>>
*Date: *Friday, March 9, 2018 at 4:48 PM
*To: *"Peter Psenak (ppsenak)" <[email-masked]<mailto:[email-masked]>>,
"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
*Cc: *"Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>,
"[email-masked]<mailto:[email-masked]>"
<[email-masked]<mailto:[email-masked]>>, BIER WG
<[email-masked]<mailto:[email-masked]>>, The IESG <[email-masked]<mailto:[email-masked]>>, Alvaro Retana
<[email-masked]<mailto:[email-masked]>>
*Subject: *Re: [Bier] Alvaro Retana's No Objection on
draft-ietf-bier-ospf-bier-extensions-14: (with COMMENT)

Hi Peter,

was deferred), means that when this is approved, it'll have to have an
RFC Editor Note to

hold it until that Status Update is approved (or bis versions are
issued, if necessary).

I do not know if resolving of the Discusses will happen by Weds of
IETF.  If not, then the

draft will not have a Yes ballot (unless Alvaro changes his) and may
need to go back through

IESG Evaluation.

Regards,

Alia

On Tue, Mar 6, 2018 at 5:17 PM, Tony Przygienda
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> wrote:

   OK,

   On OSPF I still see Suresh & Eric in discuss. Peter, did we address
   those comments ?

   thanks

   --- tony

   On Thu, Mar 1, 2018 at 7:57 PM, Tony Przygienda
   <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> wrote:

       Everyone, this constitutes a 7 days last call limited to changes
       in versions -14 and -15

       thanks

       --- tony

       On Fri, Feb 23, 2018 at 6:58 AM, Alvaro Retana
       <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> wrote:

           Peter:

           Alvaro.

           On February 23, 2018 at 8:16:49 AM, Peter Psenak
           ([email-masked]<mailto:[email-masked]><mailto:[email-masked]>) wrote:

               Hi Alvaro,

               On 23/02/18 00:14 , Alvaro Retana wrote:
               > On February 22, 2018 at 11:57:08 AM, Peter Psenak ([email-masked]<mailto:[email-masked]><mailto:[email-masked]>

               ##PP

               "If the MT-ID value is outside of the values specified
               in [RFC4915], the
               BIER Sub-TLV MUST be ignored."

               rfc8279, section 5 says:

               " If BFR-A determines that BFR-B and BFR-C have both
               advertised the
               same BFR-id for the same sub-domain, BFR-A MUST log an
               error.
               Suppose that the duplicate BFR-id is "N". When BFR-A is
               functioning as a BFIR, it MUST NOT encode the BFR-id
               value N in
               the BIER encapsulation of any packet that has been
               assigned to the
               given sub-domain, even if it has determined that the
               packet needs
               to be received by BFR-B and/or BFR-C.

               This will mean that BFR-B and BFR-C cannot receive
               multicast
               traffic at all in the given sub-domain until the
               provisioning
               error is fixed. However, that is preferable to having them
               receive each other's traffic.

               ...

               If a BFR advertises that it has a BFR-id of 0 in a
               particular
               sub-domain, other BFRs receiving the advertisement MUST
               interpret
               that advertisement as meaning that the advertising BFR
               does not have
               a BFR-id in that sub-domain."

               "All BFRs MUST detect advertisement of duplicate valid
               BFR-IDs for a
               given MT-ID and Sub-domain-ID. When such duplication is
               detected by the
               BFR, it MUST behave as described in section 5 of
               [RFC8279]."

               > Well…there are some reserved values… rfc3032…

               How to deal with the reserved labels by BIER should have
               been defined in
               rfc8296 or rfc8279, not in the IGP extension draft
               really. I have
               removed the following text:

               "All advertised labels MUST be valid, otherwise the BIER
               sub-TLV MUST be
               ignored.

               thanks,
               Peter

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

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