Subject: Re: [mpls] MPLS-RT review of [email-masked]

From: Lizhong Jin<[email-masked]>
Date: Thu, 30 Aug 2012 23:06:13 +0800

Hi Authors,
I review this draft, and have following questions:
1. Fate separation is not easy by using multiple instance, you still share 
same CPU, memory, or even same physical interface. Anyway, this is not a 
question.
2. For LDP multiple instance, is it allowed for duplicated FEC between two 
instance?
3. If duplicated FECs are possible between two instance, receiving same 
label mapping from parallel multi-lsr peering sessions could not interpret 
as loop, right?
4. In case 1~4, one interface will serve multiple instance, I guess, the 
interface you refer is physical interface, and when sharing one physical 
interface, then one sub-interface for each instance is still required, 
right? In my understanding, one IP interface could not be shared by 
multiple LDP instance, otherwise how to treat the prefix of that 
interface.

Hope to see your clarification. Thanks.

Lizhong

Loa Andersson <[email-masked]> wrote 2012/08/29 17:10:01:

> Kamran. Eric and Lizhong,
> 
> You have been selected as an MPLS Review team reviewers for
> draft-pdutta-mpls-multi-ldp-instance-00.txt.
> 
> Note to authors: You have been CC’d on this email so that you can know
> that this review is going on. However, please do not review your own
> document.
> 
> Reviews should comment on whether the document is coherent, is it useful
> (ie, is it likely to be actually useful in operational networks), and is
> the document technically sound?  We are interested in knowing whether
> the document is ready to be considered for WG adoption (ie, it doesn’t
> have to be perfect at this point, but should be a good start).
> 
> Reviews should be sent to the document authors, WG co-chairs and
> secretary, and CC’d to the MPLS WG email list. If necessary, comments
> may be sent privately to only the WG chairs.
> 
> Are you able to review this draft by Sep 13, 2012?
> 
> Thanks, Loa
> (as MPLS WG chair)
> -- 
> 
> 
> Loa Andersson                         email: [email-masked]
> Sr Strategy and Standards Manager            [email-masked]
> Ericsson Inc                          phone: +46 10 717 52 13
>                                               +46 767 72 92 13
>

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Thu, 30 Aug 2012 22:30:53 +0530

Hi Lizhong,
                  Thanks for your review. Pls refer my answers inline.

Thanks,
Pranjal

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lizhong Jin
Sent: Thursday, August 30, 2012 8:06 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] MPLS-RT review of [email-masked]

Hi Authors,
I review this draft, and have following questions:
1. Fate separation is not easy by using multiple instance, you still share same CPU, memory, or even same physical interface. Anyway, this is not a question.

[Pranjal] Fate separation has different contexts such as - TCP channel separation, avoid head of line blocking between families sharing same
TCP channel (e.g intensive PW status signaling blocking other transport tunnel events such as mLdp MBB failover etc) or fate separation of
physical/computational resources. Within a single chassis/system there are techniques to separate fate separation of computational resources
to a "certain extent". However the least common denominator for control plane fate separation is separation of TCP sessions, which the draft
addresses. It is also possible that loopbacks used for each || TCP session are fate separated by IGP multi-topology/Routing policies etc.

2. For LDP multiple instance, is it allowed for duplicated FEC between two instance?

[Pranjal] Duplicated FECs won't be allowed. The parallel sessions between two peering systems needs to be disjoint with respect to the working set
- the FECs. This needs to be ensured thru various FEC specific session capabilities. Each || session must advertise disjoint FEC capabilities. Section
2.1.1 explains the use of LDP session capabilities (RFC5561) to keep the FEC distribution mutually exclusive. What criteria to be used for segregation
of FECs are to be decided on case to case basic. This draft provides the fundamental building block for control plane fate separation.

3. If duplicated FECs are possible between two instance, receiving same label mapping from parallel multi-lsr peering sessions could not interpret as loop, right?

[Pranjal] Duplicated FECs are not allowed across . But what if a peering system misbehaves or peering system not supporting the solution (thus agnostic
Of the fact that a few sessions are terminated in same peering system) leaks FECs on all || sessions? That may result in a loop for some applications
and "Section 3. Detection of multi-instance peering" addresses that issue.  It lets a system aware of || sessions and thus can take necessary actions.

4. In case 1~4, one interface will serve multiple instance, I guess, the interface you refer is physical interface, and when sharing one physical interface, then one sub-interface for each instance is still required, right? In my understanding, one IP interface could not be shared by multiple LDP instance, otherwise how to treat the prefix of that interface.

[Pranjal] I won't view it as sub-interface since all instances are running in same FEC database. So if we think from a "virtual router" point of view (each
Virtual Router is separated across all verticals in RIB/LFIB/FIB and self-sufficient) then all the multiple LSR instances would be running within same
Virtual Router and thus can share interfaces assigned to that Virtual Router. Although the draft does not prevent usage of same Interface across all LSRs
in practice it is desirable to fate separate the physical topology to achieve separation across entire vertical. Separation of physical topology can be
achieved by LDP Multi-topology that synchronizes IGP and LDP's view (http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-04) or by using hello
adjacency capabilities at LDP level (http://tools.ietf.org/html/draft-pdutta-mpls-ldp-adj-capability-00).

Lizhong

Loa Andersson <[email-masked]> wrote 2012/08/29 17:10:01:

> Note to authors: You have been CC'd on this email so that you can know
> the document is ready to be considered for WG adoption (ie, it doesn't
> secretary, and CC'd to the MPLS WG email list. If necessary, comments

---

From: Lizhong Jin<[email-masked]>
Date: Fri, 31 Aug 2012 14:42:23 +0800

Hi Pranjal,
Thanks for the clarification, much clear than before for me now. Please 
see inline for addtional comments.

One more question for section 3.
"When a LSR receives a FEC label mapping from a peering session but same 
FEC mapping has been already receiver over another peering session 
associated with same Node-ID then the receiving LSR MUST send a Label 
Release to the peering session with statuc code"
How a LSR could know the FEC mapping information from another instance? Do 
you mean the two instance need to synchronize FEC mapping information?

Thanks
Lizhong

"Dutta, Pranjal K (Pranjal)" <[email-masked]> wrote 
2012/08/31 01:00:53:

> [Pranjal] Duplicated FECs won’t be allowed. The parallel sessions 
> between two peering systems needs to be disjoint with respect to the
> working set 
> – the FECs. This needs to be ensured thru various FEC specific 
> session capabilities. Each || session must advertise disjoint FEC 
> capabilities. Section 
> 2.1.1 explains the use of LDP session capabilities (RFC5561) to keep
> the FEC distribution mutually exclusive. What criteria to be used 
> for segregation 
> of FECs are to be decided on case to case basic. This draft provides
> the fundamental building block for control plane fate separation.
[Lizhong] Then does the LDP multiple instance in this draft does not 
include the VRF case? It is better to explicit describe this, otherwise it 
is confusing. In the VRF case, the FEC will be duplicated between 
different instances.

> 
> 3. If duplicated FECs are possible between two instance, receiving 
> same label mapping from parallel multi-lsr peering sessions could 
> not interpret as loop, right? 
> 
> [Pranjal] Duplicated FECs are not allowed across . But what if a 
> peering system misbehaves or peering system not supporting the 
> solution (thus agnostic 
> Of the fact that a few sessions are terminated in same peering 
> system) leaks FECs on all || sessions? That may result in a loop for
> some applications 
> and “Section 3. Detection of multi-instance peering” addresses that 
> issue.  It lets a system aware of || sessions and thus can take 
> necessary actions.
[Lizhong] If the FEC set (identified by capability) is totally disjoint 
between two instance, it could be simply discard the FEC label mapping if 
not match capability to avoid loop, why we still need Node-ID TLV？

> 
> 4. In case 1~4, one interface will serve multiple instance, I guess,
> the interface you refer is physical interface, and when sharing one 
> physical interface, then one sub-interface for each instance is 
> still required, right? In my understanding, one IP interface could 
> not be shared by multiple LDP instance, otherwise how to treat the 
> prefix of that interface. 

> [Pranjal] I won’t view it as sub-interface since all instances are 
> running in same FEC database. So if we think from a “virtual router”
> point of view (each 
> Virtual Router is separated across all verticals in RIB/LFIB/FIB and
> self-sufficient) then all the multiple LSR instances would be 
> running within same 
> Virtual Router and thus can share interfaces assigned to that 
> Virtual Router. Although the draft does not prevent usage of same 
> Interface across all LSRs 
> in practice it is desirable to fate separate the physical topology 
> to achieve separation across entire vertical. Separation of physical
> topology can be 
> achieved by LDP Multi-topology that synchronizes IGP and LDP’s view (
> http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-04) or
> by using hello 
> adjacency capabilities at LDP level (http://tools.ietf.
> org/html/draft-pdutta-mpls-ldp-adj-capability-00).
> 
>

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Fri, 31 Aug 2012 22:51:32 +0530

Hi Lizhong,
                        Please refer my answers inline.
Thanks,
Pranjal

________________________________
From: Lizhong Jin [mailto:[email-masked]]
Sent: Thursday, August 30, 2012 11:42 PM
To: Dutta, Pranjal K (Pranjal)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] MPLS-RT review of [email-masked]

Hi Pranjal,
Thanks for the clarification, much clear than before for me now. Please see inline for addtional comments.

One more question for section 3.
"When a LSR receives a FEC label mapping from a peering session but same FEC mapping has been already receiver over another peering session associated with same Node-ID then the receiving LSR MUST send a Label Release to the peering session with statuc code"
How a LSR could know the FEC mapping information from another instance? Do you mean the two instance need to synchronize FEC mapping information?

[Pranjal] One way to think is  as follows - let’s say that detection of multi-instance peering is implemented as in Section 3. Then receiving system would know about the sessions terminating
in same remote peering system. So the receiving system can create a group/bundle id internally for all such || sessions and keep the FEC-label mappings also in the database. If there is a
collision of Fec label mappings in the group-id database then label release can be sent, keeping the first one intact.

Thanks
Lizhong

"Dutta, Pranjal K (Pranjal)" <[email-masked]> wrote 2012/08/31 01:00:53:

> - the FECs. This needs to be ensured thru various FEC specific
[Lizhong] Then does the LDP multiple instance in this draft does not include the VRF case? It is better to explicit describe this, otherwise it is confusing. In the VRF case, the FEC will be duplicated between different instances.

> issue.  It lets a system aware of || sessions and thus can take
[Lizhong] If the FEC set (identified by capability) is totally disjoint between two instance, it could be simply discard the FEC label mapping if not match capability to avoid loop, why we still need Node-ID TLV？

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Fri, 31 Aug 2012 23:08:39 +0530

Hi Lizhong,
                     I think I didn’t clarify on - “Do you mean the two instance need to synchronize FEC mapping information”. The multi-instance peering that we described about
Is a little different from multi-instance IGPs. In multi-instance LDP case by default the FEC database would be shared in the sense that all label mapping would share the same
global label space and thus following is possible/desirable.

                          System A                                         System B                                 System C
                              LSR-A1----------------------------LSR-B1    X    LSR-B3--------------------------LSR-C1
                              LSR-A2 ---------------------------LSR-B2    X    LSR-B4--------------------------LSR-C2

                     There can be a seamless LSP/Tunnel between System A and System C for FEC F1. C->B label mapping L1 is exchanged using B3-C1 LSR tuples and
B->A label mapping L2 is exchanged using B2-A2 LSR tuples. This is because the FEC-Label mapping database continue to exist in system B in same
way as it does today. There would be only one FEC F1 in the LIB :

                                                                             F1  --> egress label L1 (Local LSR B3---Remote LSR C1)
                                                                                   --->ingress label L2 (Local LSR B2---Remote LSR A2)

                     The X connect at system B is L1->L2

Thanks,
Pranjal
________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dutta, Pranjal K (Pranjal)
Sent: Friday, August 31, 2012 10:22 AM
To: Lizhong Jin
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] MPLS-RT review of [email-masked]

Hi Lizhong,

Hi Pranjal,

Thanks
Lizhong