Subject: [PWE3] queries on draft-ietf-pwe3-pw-mib

From: Shailender Potharaju <[email-masked]>
Date: Wed, 8 Nov 2006 16:15:56 +0530

Hi,
I have few queries on using some objects mentioned draft-ietf-pwe3-pw-mib.
1. I would like to know the usage of objects pwSetUpPriority and
pwHoldingPriority which are not part of RFC4447. And I understand these are
releated to MPLS-TE tunnels where one tunnel can preempt the other. As
pseudo-wires are provisioned over tunnels, what is the use of having these
objects in the context of PW. Am I missing something here?

2. In the description of object pwLocalGroupID it is mentioned that, it is
applicable only if the owner type is pwIdFecSignaling or l2tp. But the mib
doesn't address how to represent PW Grouping-ID, which is used in
Generalized FEC. It has the same purpose as GroupID in PWID FEC. I think the
same object could be used to represent the PW Grouping-ID if the owner type
is genFecSignaling.

3. The value of the object pwMplsMplsType defined in mib
draft-ietf-pwe3-pw-mpls-mib can be mplsTe, mplsNonTe and pwOnly. As
mplsNonTe can either be manullay created (static lsp) or dynamic. I think
instead of mplsNonTe, it can be further expanded for implementation
convenience. I have another doubt regarding pwOnly case. Is it possible to
provision pseudo-wire without having mpls tunnel. I think this is possible
only if the pseudo-wire endpoints (LSRs) are directly connected. If I'm
right, the value pwOnly should be limited to read-only (may be the
implementation has to take care of this).

Regards
Shailender

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "David Zelig" <[email-masked]>
Date: Wed, 8 Nov 2006 13:15:03 +0200

Shailender,
Please see inside

>  -----Original Message-----
>  From: Shailender Potharaju [mailto:[email-masked]] 
>  Sent: Wednesday, November 08, 2006 12:46 PM
>  To: [email-masked]
>  Subject: [PWE3] queries on draft-ietf-pwe3-pw-mib
>  
>  Hi,
>  1. I would like to know the usage of objects pwSetUpPriority 
>  and pwHoldingPriority which are not part of RFC4447. And I 
>  understand these are releated to MPLS-TE tunnels where one 
>  tunnel can preempt the other. As pseudo-wires are 
>  provisioned over tunnels, what is the use of having these 

[DZ] The intention is that you will have similar capabilities to MPLS-TE
holding and setup. Because the usage is local to the edge node, they do
not need to part of the signaling defined in RFC4447.

>  
>  2. In the description of object pwLocalGroupID it is 
>  mentioned that, it is applicable only if the owner type is 
>  pwIdFecSignaling or l2tp. But the mib doesn't address how to 
>  represent PW Grouping-ID, which is used in Generalized FEC. 
>  It has the same purpose as GroupID in PWID FEC. I think the 
>  same object could be used to represent the PW Grouping-ID if 
>  the owner type is genFecSignaling.
>  
[DZ] pwGroupAttachmentID represents the equivalent to pwLocalGroupID for
generalized FEC.

>  draft-ietf-pwe3-pw-mpls-mib can be mplsTe, mplsNonTe and 
>  pwOnly. As mplsNonTe can either be manullay created (static 
>  lsp) or dynamic. I think instead of mplsNonTe, it can be 
>  further expanded for implementation convenience. I have 
>  another doubt regarding pwOnly case. Is it possible to 
>  provision pseudo-wire without having mpls tunnel. I think 
>  this is possible only if the pseudo-wire endpoints (LSRs) 
>  are directly connected. If I'm right, the value pwOnly 
>  should be limited to read-only (may be the implementation 
>  has to take care of this).

[DZ] You are right that pwOnly is just for end-points that are directly
connected and when the PW is manually configured, but how the
implementation will know that this is the case? With manual
configuration you may still have PW with and without tunnel.

David

---

From: Shailender Potharaju <[email-masked]>
Date: Wed, 8 Nov 2006 17:08:40 +0530

Hi David,
Thanks for your reply.

I think pwGroupAttachementID represents AGI used in Generalized FEC. AGI is
different from Grouping ID. For point to point pseudo-wires the AGI is 0.
And, if the pseudo-wires are bound to VPLS instance (mesh vcs), the AGI
would be the vpls-id (vpnId). Please correct me if I'm wrong.

Regarding pwOnly case, it should be not be difficult at implementation to
know whether the LSRs are directly connected. I think next hop address could
be used to identify whether they are directly connected.

Regards
Shailender

-----Original Message-----
From: David Zelig [mailto:[email-masked]]
Sent: Wednesday, November 08, 2006 4:45 PM
To: Shailender Potharaju; [email-masked]
Subject: RE: [PWE3] queries on draft-ietf-pwe3-pw-mib

Shailender,
Please see inside

David

---

From: "David Zelig" <[email-masked]>
Date: Fri, 17 Nov 2006 10:57:57 +0200

Shailender.

-----Original Message-----
From: Shailender Potharaju [mailto:[email-masked]] 
Sent: Wednesday, November 08, 2006 1:39 PM
To: David Zelig; [email-masked]
Subject: RE: [PWE3] queries on draft-ietf-pwe3-pw-mib

Hi David,
Thanks for your reply.

I think pwGroupAttachementID represents AGI used in Generalized FEC. AGI
is different from Grouping ID. For point to point pseudo-wires the AGI
is 0.
And, if the pseudo-wires are bound to VPLS instance (mesh vcs), the AGI
would be the vpls-id (vpnId). Please correct me if I'm wrong.

[DZ] You are right, I will fix it to include also the generalized FEC.

Regarding pwOnly case, it should be not be difficult at implementation
to know whether the LSRs are directly connected. I think next hop
address could be used to identify whether they are directly connected.

[DZ} May be I miss something, but even if you know somehow that they are
directly connected, the value of pwOnly cannot be limited to read-only
since I am not sure we should enforce all the implementations to
automatically detect the neighbor is directly connected. I can allow it
to be read only through the conformance description;

Thanks
David

Regards
Shailender

-----Original Message-----
From: David Zelig [mailto:[email-masked]]
Sent: Wednesday, November 08, 2006 4:45 PM
To: Shailender Potharaju; [email-masked]
Subject: RE: [PWE3] queries on draft-ietf-pwe3-pw-mib

Shailender,
Please see inside

> pwHoldingPriority which are not part of RFC4447. And I  understand 
> these are releated to MPLS-TE tunnels where one  tunnel can preempt 
> the other. As pseudo-wires are  provisioned over tunnels, what is the 
> use of having these  objects in the context of PW. Am I missing 
> something here?

>
>  2. In the description of object pwLocalGroupID it is  mentioned that,

> it is applicable only if the owner type is  pwIdFecSignaling or l2tp. 
> But the mib doesn't address how to  represent PW Grouping-ID, which is

> used in Generalized FEC.
>  It has the same purpose as GroupID in PWID FEC. I think the  same 
> object could be used to represent the PW Grouping-ID if  the owner 
> type is genFecSignaling.
>

> mplsNonTe can either be manullay created (static
>  lsp) or dynamic. I think instead of mplsNonTe, it can be  further 
> expanded for implementation convenience. I have  another doubt 
> regarding pwOnly case. Is it possible to  provision pseudo-wire 
> without having mpls tunnel. I think  this is possible only if the 
> pseudo-wire endpoints (LSRs)  are directly connected. If I'm right, 
> the value pwOnly  should be limited to read-only (may be the 

David