Subject: Re: [Isis-wg] Proposed isis-wg documents - draft-ginsberg-isis-sbfd-discriminator-00

From: Uma Chunduri <[email-masked]>
Date: Thu, 21 Aug 2014 03:03:39 +0000

Support this.

Qs:

1. What happened to the discussion on-  if this discriminator is a link property or node property as defined (asked originally in OSPF WG by Hannes).
2. If MTs are on the same physical topology, I don't see the association of Discriminator to the logical topology/MT.  Is it already though and discounted ? If yes rationale will be helpful.

--
Uma C.

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of Christian Hopps
Sent: Tuesday, August 19, 2014 4:48 AM
To: [email-masked] list
Cc: Hannes Gredler; Christian Hopps
Subject: [Isis-wg] Proposed isis-wg documents.

Hi Folks,

During the last meeting in Toronto there was good support for making the below drafts WG documents. Unless objections are posted to the list by Friday we will move forward with doing this.

Proposed WG Documents:

	draft-ginsberg-isis-sbfd-discriminator-00
	draft-ginsberg-isis-route-preference-00
	draft-litkowski-isis-yang-isis-cfg-01

Thanks,
Chris & Hannes.
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 21 Aug 2014 03:48:03 +0000

Uma -

> From: Isis-wg [mailto:[email-masked]] On Behalf Of Uma
> Chunduri
> Sent: Wednesday, August 20, 2014 8:04 PM
> To: Christian Hopps; [email-masked] list
> Cc: Hannes Gredler
> Subject: Re: [Isis-wg] Proposed isis-wg documents - draft-ginsberg-isis-sbfd-
> discriminator-00
> 
> Support this.
> 
> Qs:
> 
> 1. What happened to the discussion on-  if this discriminator is a link
> property or node property as defined (asked originally in OSPF WG by
> Hannes).

The question was answered - discriminators are a node property.

> 2. If MTs are on the same physical topology, I don't see the association of
> Discriminator to the logical topology/MT.  Is it already though and
> discounted ? If yes rationale will be helpful.

Just as IP/IPv6 addresses are NOT topology specific, S-BFD discriminators are NOT topology specific. The paths to reach a node may differ between topologies - but that is not a property of the discriminator.

   Les

> During the last meeting in Toronto there was good support for making the
> below drafts WG documents. Unless objections are posted to the list by
> Friday we will move forward with doing this.
> 
> Proposed WG Documents:
>

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 21 Aug 2014 06:59:34 +0000

Les,

In-line [Uma1]:

===
> Support this.
> 
> Qs:
> 
> 1. What happened to the discussion on-  if this discriminator is a 
> link property or node property as defined (asked originally in OSPF WG 
> by Hannes).

[Uma1]: I saw SR use cases for SBFD and with ADJ-SID's (link specific)  this can be a problem.

> 2. If MTs are on the same physical topology, I don't see the 
> association of Discriminator to the logical topology/MT.  Is it 
> already though and discounted ? If yes rationale will be helpful.

[Uma1]:  A node may  be part of any  logical topology (MT) or may not be. 
But, if the discriminator doesn't represent the same then the receiving node (participating in multiple logical topologies) has no idea  for which topo the same has been received or
In other words  sending node may not be part of the particular logical topo.

Do you see this as an issue?

--
Uma C.

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 21 Aug 2014 13:04:50 +0000

Hi Uma, Les,

Pardon me for jumping in.
Please see [NOBO] in-line.

> Sent: Thursday, August 21, 2014 3:00 AM
> To: Les Ginsberg (ginsberg); Christian Hopps; [email-masked] list
> Cc: Hannes Gredler

[NOBO] Couple of comments.
1. S-BFD document for Segment Routing is very stale. Authors should be able to roll out a revised and updated document this weekend.
2. S-BFD authors wanted to build in some connectivity test aspect into the S-BFD mechanism, particularly to allow verifying where Adj-SID terminates on the nextshop. However, there were strong push backs from the BFD WG regarding usage of BFD or S-BFD for connectivity test. Thus, S-BFD focuses only on continuity check, which is a node reachability check.

> Just as IP/IPv6 addresses are NOT topology specific, S-BFD discriminators are
> NOT topology specific. The paths to reach a node may differ between
> topologies - but that is not a property of the discriminator.
> 
> But, if the discriminator doesn't represent the same then the receiving node
> (participating in multiple logical topologies) has no idea  for which topo the
> same has been received or In other words  sending node may not be part of
> the particular logical topo.
> 

[NOBO] This is a very good comment Uma. My response would be that there's nothing in S-BFD documents that prevents tying of local S-BFD discriminator to set of incoming interfaces. i.e. a local S-BFD discriminator for an MT can programmed to process S-BFD packets coming in only from set of interfaces which belong in the MT. If such strict checks are desired, implementations are free to do so.

Thanks!

-Nobo

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 21 Aug 2014 21:02:46 +0000

Uma/Nobo -

The MT question has nothing to do w S-BFD - it is a generic issue for any type of BFD multi-hop session. If you have multiple topologies for a given address family and you would like the BFD packets to traverse a specific topology then you have to "mark"  BFD packets in the same way that data packets are marked for a given topology.  Then the packets will be processed at each hop along the way based on topology specific forwarding. What this marking is has nothing to do with BFD - and it certainly would NOT be a BFD discriminator as this would be specific to BFD packets only - which is not at all what you want.

   Les

> From: Nobo Akiya (nobo)
> Sent: Thursday, August 21, 2014 6:05 AM
> To: Uma Chunduri; Les Ginsberg (ginsberg); Christian Hopps; isis-
> [email-masked] list
> Cc: Hannes Gredler
> Subject: RE: [Isis-wg] Proposed isis-wg documents - draft-ginsberg-isis-sbfd-
> discriminator-00
> 
> Hi Uma, Les,
> 
> 1. S-BFD document for Segment Routing is very stale. Authors should be
> able to roll out a revised and updated document this weekend.
> 2. S-BFD authors wanted to build in some connectivity test aspect into the S-
> BFD mechanism, particularly to allow verifying where Adj-SID terminates on
> the nextshop. However, there were strong push backs from the BFD WG
> regarding usage of BFD or S-BFD for connectivity test. Thus, S-BFD focuses
> only on continuity check, which is a node reachability check.
> 
> >
> [NOBO] This is a very good comment Uma. My response would be that
> there's nothing in S-BFD documents that prevents tying of local S-BFD
> discriminator to set of incoming interfaces. i.e. a local S-BFD discriminator
> for an MT can programmed to process S-BFD packets coming in only from set
> of interfaces which belong in the MT. If such strict checks are desired,
> implementations are free to do so.
> 
> Thanks!
> 
> -Nobo
> 
> >
> > --
> > Uma C.
> >

---

From: Uma Chunduri <[email-masked]>
Date: Sun, 24 Aug 2014 07:26:33 +0000

Dear Nobo,

	> discriminator to set of incoming interfaces. i.e. a local S-BFD 
	> discriminator for an MT can programmed to process S-BFD packets coming 
	> in only from set of interfaces which belong in the MT. If such strict 
	> checks are desired, implementations are free to do so.

I am not talking about the S-BFD packet, rather the S-BFD discriminator received  at an MT interface/MT node. 
The received one might be associated for only one or set of MTs by the sender. IMO, (in one way) this could be represented only when an MT-ID (5120) is associated with the discriminator. 

Dear Les,

             > The MT question has nothing to do w S-BFD - it is a generic issue for any type of BFD multi-hop session.
             >  If you have multiple topologies for a given address family and you would like the BFD packets to traverse 
             > a specific topology then you have to "mark"  BFD packets in the same way that data packets are marked for
             > a given topology.  

As I clarified above my question was about association of discriminator to MT ID...
If you think it's not necessary I have no issues!

--
Uma C.

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Thursday, August 21, 2014 2:03 PM
To: Nobo Akiya (nobo); Uma Chunduri; Christian Hopps; [email-masked] list
Cc: Hannes Gredler
Subject: RE: [Isis-wg] Proposed isis-wg documents - draft-ginsberg-isis-sbfd-discriminator-00

Uma/Nobo -

   Les

> > Subject: Re: [Isis-wg] Proposed isis-wg documents - 
> > draft-ginsberg-isis-
> sbfd-
> > discriminator-00
> >
> > Les,
> >
> > In-line [Uma1]:
> >
> > ===
> > > Support this.
> > >
> > > Qs:
> > >
> > > link property or node property as defined (asked originally in 
> > > OSPF WG by Hannes).
> >
> 2. S-BFD authors wanted to build in some connectivity test aspect into 
> the S- BFD mechanism, particularly to allow verifying where Adj-SID 
> terminates on the nextshop. However, there were strong push backs from 
> the BFD WG regarding usage of BFD or S-BFD for connectivity test. 
> Thus, S-BFD focuses only on continuity check, which is a node reachability check.
> 
> >
> > Just as IP/IPv6 addresses are NOT topology specific, S-BFD 
> > discriminators
> are
> > But, if the discriminator doesn't represent the same then the 
> > receiving
> node
> > (participating in multiple logical topologies) has no idea  for 
> > which topo
> the
> > same has been received or In other words  sending node may not be 
> > part
> of
> discriminator to set of incoming interfaces. i.e. a local S-BFD 
> discriminator for an MT can programmed to process S-BFD packets coming 
> in only from set of interfaces which belong in the MT. If such strict 
> checks are desired, implementations are free to do so.
> 
> Thanks!
> 
> -Nobo
> 
> >
> > --
> > Uma C.
> >

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sun, 24 Aug 2014 12:51:02 +0000

Hi Uma,

> From: Uma Chunduri [mailto:[email-masked]]
> Sent: Sunday, August 24, 2014 3:27 AM
> To: Les Ginsberg (ginsberg); Nobo Akiya (nobo); Christian Hopps; isis-
> [email-masked] list
> Cc: Hannes Gredler
> The received one might be associated for only one or set of MTs by the
> sender. IMO, (in one way) this could be represented only when an MT-ID
> (5120) is associated with the discriminator.

Ok I see what you are saying. I agree with Les that we do not want to use discriminator to classify the MT ID, rather use something in the lower layer to achieve that.

Thanks!

-Nobo

>              > a specific topology then you have to "mark"  BFD packets in the
> same way that data packets are marked for
>              > a given topology.
> 
> The MT question has nothing to do w S-BFD - it is a generic issue for any type
> of BFD multi-hop session. If you have multiple topologies for a given
> address family and you would like the BFD packets to traverse a specific
> topology then you have to "mark"  BFD packets in the same way that data
> packets are marked for a given topology.  Then the packets will be
> processed at each hop along the way based on topology specific forwarding.
> What this marking is has nothing to do with BFD - and it certainly would NOT
> be a BFD discriminator as this would be specific to BFD packets only - which
> is not at all what you want.
> 
>    Les
> 
>