Re: [Isis-wg] New Version/Proposed isis-wg documents draft-ginsberg-isis-sbfd-discriminator-00.txt

Hello everyone,

think I missed some discussions as they showed as "ISIS" WG. So my apology 
for bringing this up again but ...

looking at draft-ginsberg-isis-sbfd-discriminator-00 there is this part in 
the document:

   Inclusion of the S-BFD Discriminators sub-TLV in a Router Capability
   TLV is optional.  Multiple S-BFD Discriminators sub-TLVs MAY be
   advertised by an IS.  When multiple S-BFD discriminators are
   advertised how a given discriminator is mapped to a specific use case
   is out of scope for this document.

There is something right about it, at the same time something is missing, 
IMHO.

How BFD is using the discriminator value(s) is likely something the IS-IS 
protocol does not want to know; it would create interdependencies and 
complexity.

On the other hand the solution does not provide enough context for each 
discriminator. For a single discriminator - fine, no choice anyway. But 
transporting multiple discriminators without context seems "useless" to me.

I would have expected a slightly different layout:

                                                  No. of octets
                 +-----------------------------+
                 | Type (to be assigned by     |     1
                 | IANA)  |
                 +-----------------------------+
                 | Length (multiple of 8)      |     1
                 +-----------------------------+
                 | Discriminator Value         |     4 per Discriminator
                 | Context Value               |     4 (?) per Context
                 : (potentially more pairs of  :
                 :  Discriminator/Context)     :  
                 +-----------------------------+

How many bits per Context value can be discussed; I used 32bit due to lack of 
fantasy ;-)  What a "context value" is/means doesn't matter to IS-IS, it just 
transports it. But the IS-IS clients - be it BFD or BFD clients - can use it.

We don't even need to discuss the details of a Context Value within the BFD 
WG for now but not having any value for administrative purposes seems 
"jumping short" to me (think communities in BGP, route tags in certain RIB 
implementations etc.)

Again, sorry for commenting with a delay of "only" a few month :-)

Regards, Marc

On Wed, 21 May 2014 01:24:37 +0000, Nobo Akiya (nobo) wrote:
> Thanks for prompt response Greg.
> 
> Will incorporate the text in draft-ietf-...-01.
> 
> -Nobo
> 
>> -----Original Message-----
>> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
>> Sent: Tuesday, May 20, 2014 9:22 PM
>> To: Nobo Akiya (nobo); Mach Chen; Hannes Gredler
>> Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org
>> Subject: RE: [Isis-wg] New Version Notification for 
>> draft-ginsberg-isis-sbfd-
>> discriminator-00.txt
>> 
>> Hi Nobo,
>> I like it.
>> 
>> 	Regards,
>> 		Greg
>> 
>> -----Original Message-----
>> From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]
>> Sent: Tuesday, May 20, 2014 6:18 PM
>> To: Gregory Mirsky; Mach Chen; Hannes Gredler
>> Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org
>> Subject: RE: [Isis-wg] New Version Notification for 
>> draft-ginsberg-isis-sbfd-
>> discriminator-00.txt
>> 
>> Hi Greg,
>> 
>> That's true, the whole paragraph in the section 7 of S-BFD base document is
>> just describing some possible implementation techniques. How about we
>> change the paragraph:
>> 
>> [old]
>>    Note that incoming BFD control packets destined to BFD target
>>    identifier types may be IPv4, IPv6 or MPLS based.  For those BFD
>>    target identifier types, implementations MAY either allow the same
>>    reflector BFD session to handle all incoming BFD control packets in
>>    address family agnostic fashion, or setup multiple reflector BFD
>>    sessions to handle incoming BFD control packets with different
>>    address families.  This policy is again a local matter, and is
>>    outside the scope of this document.
>> 
>> [new]
>>    Note that incoming BFD control packets destined to BFD target
>>    identifier types may be IPv4, IPv6 or MPLS based.  How such packets
>>    reach an appropriate reflector BFD session is a local matter, and is
>>    outside the scope of this document.
>> 
>> -Nobo
>> 
>>> -----Original Message-----
>>> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
>>> Sent: Tuesday, May 20, 2014 6:46 PM
>>> To: Nobo Akiya (nobo); Mach Chen; Hannes Gredler
>>> Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org
>>> Subject: RE: [Isis-wg] New Version Notification for
>>> draft-ginsberg-isis-sbfd- discriminator-00.txt
>>> 
>>> Dear All,
>>> according to Section 7 of the S-BFD Base document differentiation
>>> among address families by S-BFD is optional and mention in connection
>>> to separate S-BFD reflectors to act as per-AF reflectors. Perhaps I've
>>> missed that part of S-BFD Base discussion but I don't see the benefit of
>> supporting such mode.
>>> BFD control packets been AF-agnostic since RFC 5880 and I think that
>>> S-BFD should maintain that approach.
>>> 
>>> I agree with Mach that discriminators in S-BFD, as well as in BFD, are
>>> and must remain AF blind.
>>> 
>>> 	Regards,
>>> 		Greg
>>> 
>>> -----Original Message-----
>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo
>>> Akiya
>>> (nobo)
>>> Sent: Thursday, May 15, 2014 7:07 AM
>>> To: Mach Chen; Hannes Gredler
>>> Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org
>>> Subject: RE: [Isis-wg] New Version Notification for
>>> draft-ginsberg-isis-sbfd- discriminator-00.txt
>>> 
>>> Hi Mach, Hannes, et al,
>>> 
>>>> IMHO, the capability issue should not be a S-BFD specific issue,
>>>> even not BFD specified issue. It is actually a forwarding capability
>>>> issue, it is about whether the target node can process IPv4, IPv6,
>>>> MPLS, SR encapsulated BFD packets.
>>> 
>>> I agree Mach, mostly :)
>>> 
>>> I can also see one arguing that forwarding supporting X does not
>>> always mean S-BFD is supported on X. If we want to address this, then
>>> it is an S-BFD specific issue, and we _may_ want to solve this via
>>> introducing S-BFD capability advertisements.
>>> 
>>> With that said, S-BFD discriminator advertisement is one area which
>>> the capability problem can be solved, but not necessary a problem that
>>> has to be solved with S-BFD discriminator advertisement. Rather I
>>> don't think the two should be bundled together.
>>> 
>>> Let us continue the capability discussion separate from the
>>> discriminator advertisements?
>>> 
>>> -Nobo
>>> 
> 
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg
> 