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

["Acee Lindem (acee)" <[e-mail]>]

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

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

On Tue, Mar 6, 2018 at 5:17 PM, Tony Przygienda <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 ...
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 <[e-mail]<mailto:[e-mail]>> wrote:
Peter:

Hi!  Thanks for addressing my comment!

Alvaro.


On February 23, 2018 at 8:16:49 AM, Peter Psenak ([e-mail]<mailto:[e-mail]>) 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 ([e-mail]<mailto:[e-mail]>
> <mailto:[e-mail]<mailto:[e-mail]>>) 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/bier



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