[mpls] Question regarding MPLS reserved label with ECMP

["Vivek Kumar" <[e-mail]>]

Hi ,
  I have one question regarding whether MPLS reserved label should be used or skipped when Transit LSR is doing hashing on full label stack which has some reserved label.

   RFC 6391 , section 7 , says " Note that, depending on the number of labels hashed by the LSR, the
   inclusion of the Router Alert label may cause the OAM packet to be
   load-balanced to a different path from that taken by the data packets
   with identical flow and PW labels".

  The above comment implies that reserved label is used by LSR when doing hashing for ECMP. 

  Is there any other RFC which states what should be the correct behavior. 
    
  The draft " draft-ietf-mpls-entropy-label-05" section 4.3 , says reserved label should not be used by LSR when doing hashing on label stack.
  

Regards,
Vivek 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Saturday, August 18, 2012 5:12 AM
To: [e-mail]
Subject: mpls Digest, Vol 100, Issue 32

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/mpls

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.



Send mpls mailing list submissions to
	[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/mpls
or, via email, send a message with subject or body 'help' to
	[e-mail]

You can reach the person managing the list at
	[e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of mpls digest..."


Today's Topics:

   1. I-D Action: draft-ietf-mpls-entropy-label-05.txt
      ([e-mail])
   2. Re: draft-ietf-mpls-tp-te-mib-04.txt review request
      (Venkatesan Mahalingam)
   3. Re: draft-ietf-mpls-tp-te-mib-04.txt review request (Sam Aldrin)
   4. Re: [CCAMP]	I-D	Action:
      draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
      (Gregory Mirsky)


----------------------------------------------------------------------

Message: 1
Date: Fri, 17 Aug 2012 12:19:09 -0700
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: [mpls] I-D Action: draft-ietf-mpls-entropy-label-05.txt
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="utf-8"


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title           : The Use of Entropy Labels in MPLS Forwarding
	Author(s)       : Kireeti Kompella
                          John Drake
                          Shane Amante
                          Wim Henderickx
                          Lucy Yong
	Filename        : draft-ietf-mpls-entropy-label-05.txt
	Pages           : 23
	Date            : 2012-08-17

Abstract:
   Load balancing is a powerful tool for engineering traffic across a
   network.  This memo suggests ways of improving load balancing across
   MPLS networks using the concept of "entropy labels".  It defines the
   concept, describes why entropy labels are useful, enumerates
   properties of entropy labels that allow maximal benefit, and shows
   how they can be signaled and used for various applications.  This
   document updates RFCs 3031, 3107, 3209 and 5036.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-entropy-label

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mpls-entropy-label-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-entropy-label-05


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/



------------------------------

Message: 2
Date: Fri, 17 Aug 2012 13:51:19 -0700
From: Venkatesan Mahalingam <[e-mail]>
To: Joan Cucchiara <[e-mail]>, [e-mail], 	"MIB
	Doctors (E-mail)" <[e-mail]>, [e-mail]
Cc: Sam Aldrin <[e-mail]>
Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib-04.txt review request
Message-ID:
	<CA+UNA02fFWJUYv7AkXMh6FuvXpH9=[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1

++ MPLS WG & MIB Drs.

Thanks,
Venkat.

On Fri, Aug 17, 2012 at 1:36 PM, Joan Cucchiara
<[e-mail]> wrote:
> Venkat,
>
> The SMIv2 specifies that once a TC is defined, then the definition cannot
> change in the way being
> proposed by the draft-ietf-mpls-tp-te-mib-04.
>
> From RFC2579:
> 3.3.  Mapping of the DESCRIPTION clause
>  The DESCRIPTION clause, which must be present, contains a textual
>   definition of the textual convention, which provides all semantic
>   definitions necessary for implementation, and should embody any
>   information which would otherwise be communicated in any ASN.1
>   commentary annotations associated with the object.
>
>
> My concern is that MPLS-TC-STD-MIB defines MplsExtendedTunnelId and this
> draft is changing that original definition.
> If RFC3811 does not contain "all semantic definitions necessary for
> implementation" then the problem is to update RFC3811
> and maybe other associated RFCs as needed, not to propose additional
> semantics in draft-ietf-mpls-tp-te-mib.
>
> The draft is proposing to bifurcate the values and also not use zero for the
> MplsExtendedTunnelId, that is not the original
> definition of MplsExtendedTunnelId, so why is this draft using
> MplsExtendedTunnelId?
>
> Please include the MIB Dr's on your email because this is a MIB concern and
> one which I've had since
> before this draft was adopted as a WG document.
>
> The options are (as I see them):
> 1) create a specific MPLS TP table for TP Tunnels (which was originally
> proposed by Adrian Farrel)
> 2) update RFC3811 to accurately reflect MplsExtendedTunnelId and other RFCs
> which utilize this TC.
> 3) ??
>
> Thanks,
>  -Joan
>
>
> ----- Original Message ----- From: "Venkatesan Mahalingam"
> <[e-mail]>
> To: "Joan Cucchiara" <[e-mail]>
> Cc: "Thomas Nadeau" <[e-mail]>; "Sam Aldrin"
> <[e-mail]>; "Kannan KV Sampath" <[e-mail]>
> Sent: Friday, August 17, 2012 2:39 PM
>
> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request
>
>
>> Joan,
>>
>> Thanks for your response. Appreciate your time for reviewing this
>> draft. Please find below my response tagged [VM].
>>
>> However, I looked over the doc and wanted to let you know that I still
>> have
>>>
>>> the same issue wrt to both SYNTAX and semantic
>>> redefinition as before.   You cannot narrow the range of values in a
>>> DESCRIPTION clause which I see happens in mplsTunnelExtNodeConfigLocalId
>>> and maybe  in MplsNodeId TC as it says zero must not be used, but then
>>> you
>>> have it as part of allowable values in the SYNTAX.
>>
>> [VM] If MplsExtendedTunnelId allows zero as the valid value, I don't
>> see any issue to allow zero as the valid value for MplsNodeId.
>>
>>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any
>>> Unsigned32 and says "may represent an IPv4 address".    If (for whatever
>>> reason) an
>>> operator has configured something in the 1..16777216 (i.e. Local Id)
>>> range,
>>> for a regular TE Tunnel, that is perfectly legal, right?
>>
>> [VM] I don't see any implementation which allows non-IP TE tunnel
>> source/destination in the range 1..16777216 in MPLS domain,
>> if you are not still convinced, we can poll in MPLS WG list to get the
>> operators' opinion on this.
>>
>>> If the answer is Yes, then how would you add TP Tunnels using your draft
>>> if
>>> an operator has a regular MPLS TE Tunnel configured
>>> in the range 1..16777216 without having to ensure that any and all legacy
>>> equipment be queried first?
>>
>> [VM] It is expected to configure MPLS TE tunnels in IP address range
>> and MPLS-TP tunnel in NON-IP range, if the implementors have mixed
>> mode of configuration, then it is expected to clarify in the document
>> that how to use MPLS-TE & MPLS-TP tunnel configurations.
>> What you are saying is correct only if the legacy equipments use the
>> NON-IP range for MPLS TE tunnels, so, as I stated above, let's close
>> this with the MPLS WG list.
>>
>> HTH
>>
>> Thanks,
>> Venkat.
>>
>> On Fri, Aug 17, 2012 at 10:21 AM, Joan Cucchiara
>> <[e-mail]> wrote:
>>>
>>> Tom and all,
>>>
>>> Unfortunately, my linux box is giving me grief this week (and I don't
>>> have
>>> access to my MIB tools).   I'm getting some assistance
>>> with it but won't be resolved until (hopefully) during the weekend.
>>>
>>> However, I looked over the doc and wanted to let you know that I still
>>> have
>>> the same issue wrt to both SYNTAX and semantic
>>> redefinition as before.   You cannot narrow the range of values in a
>>> DESCRIPTION clause which I see happens in mplsTunnelExtNodeConfigLocalId
>>> and maybe  in MplsNodeId TC as it says zero must not be used, but then
>>> you
>>> have it as part of allowable values in the SYNTAX.
>>>
>>> Whatever is specified in the DESCRIPTION clause for values, should be
>>> reflected by the SYNTAX, right?
>>>
>>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any
>>> Unsigned32 and says "may represent an IPv4 address".    If (for whatever
>>> reason) an
>>> operator has configured something in the 1..16777216 (i.e. Local Id)
>>> range,
>>> for a regular TE Tunnel, that is perfectly legal, right?
>>>
>>>
>>>  MplsExtendedTunnelId ::= TEXTUAL-CONVENTION
>>>           STATUS        current
>>>           DESCRIPTION
>>>              "A unique identifier for an MPLS Tunnel.  This may
>>>               represent an IPv4 address of the ingress or egress
>>>               LSR for the tunnel.  This value is derived from the
>>>               Extended Tunnel Id in RSVP or the Ingress Router ID
>>>               for CR-LDP."
>>>           REFERENCE
>>>              "RSVP-TE: Extensions to RSVP for LSP Tunnels,
>>>               [RFC3209].
>>>
>>>               Constraint-Based LSP Setup using LDP, [RFC3212]."
>>>           SYNTAX  Unsigned32(0..4294967295)
>>>
>>> If the answer is Yes, then how would you add TP Tunnels using your draft
>>> if
>>> an operator has a regular MPLS TE Tunnel configured
>>> in the range 1..16777216 without having to ensure that any and all legacy
>>> equipment be queried first?
>>>
>>> Thanks,
>>>   -Joan
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From: Thomas Nadeau
>>> To: Joan Cucchiara
>>> Cc: Sam Aldrin ; Venkatesan Mahalingam ; Kannan KV Sampath
>>> Sent: Thursday, August 09, 2012 8:58 AM
>>> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request
>>>
>>> hi Joan
>>>
>>> hope you had a great vacation! ;)
>>>
>>> can you please follow up on the note below when you have a chance?
>>>
>>> Tom
>>>
>>>
>>>
>>> On Jul 16, 2012, at 9:13 AM, "Joan Cucchiara" <[e-mail]>
>>> wrote:
>>>
>>> Sam,
>>>
>>> We are away this week returning on 7/23.   Sorry, I can't review the doc
>>> until after 7/23 and it will
>>> take a few days after that as I'll just be returning from vacation.
>>>
>>> I glanced at it and see that there are read-write objects in a row (which
>>> is
>>> read-create) so that's
>>> an error which I mentioned before.
>>>
>>> Have you compiled this with smilint?
>>>
>>> Thanks,
>>>   -Joan
>>>
>>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From: Sam Aldrin
>>> To: Joan Cucchiara
>>> Cc: Venkatesan Mahalingam ; Thomas Nadeau ; Kannan KV Sampath
>>> Sent: Friday, July 13, 2012 9:11 PM
>>> Subject: Fwd: draft-ietf-mpls-tp-te-mib-04.txt review request
>>>
>>> Hi Joan,
>>>
>>> Please find the updated MIB document. Apologize for the delay. We plan to
>>> publish the doc on Monday as it is the deadline before IETF. Diff file is
>>> attached as well.
>>>
>>> This version addresses all your comments. Highlighting couple of them to
>>> make sure you are OK with them
>>>
>>> 1. W.r.t mplsLocalID as index type, we have removed that using
>>> MplsExtendedTunnelId itself. As the value range for this object could
>>> have
>>> value of non-IP address, we are using it. This will make the indices for
>>> the
>>> same as TunnelTable.
>>> In the definition of IngressLSRId and and EgressLSRId, for TP entries, we
>>> added description to use value of non-IP address, which is local ID.
>>>
>>> I do hope this satisfies the need and not necessitate for a new table
>>> altogether for TP.
>>>
>>> 2. In regards to adding references to TC conventions. We believe, those
>>> were
>>> added in the reference section. IF we have missed any TC references,
>>> could
>>> you kindly let us know.
>>>
>>> Appreciate if you can get back by Monday noon time PST. I know it is a
>>> very
>>> short time, but appreciate if you could do that.
>>>
>>> thanks
>>> -sam
>>>
>>> ________________________________
>>>
>>>
>


------------------------------

Message: 3
Date: Fri, 17 Aug 2012 14:06:45 -0700
From: Sam Aldrin <[e-mail]>
To: Venkatesan Mahalingam <[e-mail]>
Cc: [e-mail], [e-mail],	Sam Aldrin
	<[e-mail]>,	"MIB Doctors \(E-mail\)"
	<[e-mail]>
Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib-04.txt review request
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=us-ascii

Hi Joan,

The issue boils down to the range value specified in the DESCRIPTION.
If that is removed, does that resolve the concern you raised?
Do not think we are restricting not to use '0' in anyway or redefining the semantics.

As the value is local and the intention is to help implementor of the MIB to choose right value, without conflicting with TE tunnel index, we added that range. If implementor chooses to use different value altogether, it is perfectly OK as long as it is in the range of mplsExtendedTunnelId definition.
W.r.t legacy implementation, it is unto the implementor to assign the right index value to TP tunnel, if it conflicts with TE tunnel index.
The example provided could give guidance on what value to use, but will not MANDATE the usage.

In regards to implementing a new table, we have deliberated extensively among authors and also with implementors. Adding new MIB or table is not really efficient. Infact, there are already implementations which were able to support the legacy model as well as new TP tunnels. Unless there is a compelling reason that MPLS TP tunnel table should have its own table, which essentially duplicated all of the objects, I am not for that model. If others in WG feels the need, they can speak up.

-sam
On Aug 17, 2012, at 1:51 PM, Venkatesan Mahalingam <[e-mail]> wrote:

> ++ MPLS WG & MIB Drs.
> 
> Thanks,
> Venkat.
> 
> On Fri, Aug 17, 2012 at 1:36 PM, Joan Cucchiara
> <[e-mail]> wrote:
>> Venkat,
>> 
>> The SMIv2 specifies that once a TC is defined, then the definition cannot
>> change in the way being
>> proposed by the draft-ietf-mpls-tp-te-mib-04.
>> 
>> From RFC2579:
>> 3.3.  Mapping of the DESCRIPTION clause
>> The DESCRIPTION clause, which must be present, contains a textual
>>  definition of the textual convention, which provides all semantic
>>  definitions necessary for implementation, and should embody any
>>  information which would otherwise be communicated in any ASN.1
>>  commentary annotations associated with the object.
>> 
>> 
>> My concern is that MPLS-TC-STD-MIB defines MplsExtendedTunnelId and this
>> draft is changing that original definition.
>> If RFC3811 does not contain "all semantic definitions necessary for
>> implementation" then the problem is to update RFC3811
>> and maybe other associated RFCs as needed, not to propose additional
>> semantics in draft-ietf-mpls-tp-te-mib.
>> 
>> The draft is proposing to bifurcate the values and also not use zero for the
>> MplsExtendedTunnelId, that is not the original
>> definition of MplsExtendedTunnelId, so why is this draft using
>> MplsExtendedTunnelId?
>> 
>> Please include the MIB Dr's on your email because this is a MIB concern and
>> one which I've had since
>> before this draft was adopted as a WG document.
>> 
>> The options are (as I see them):
>> 1) create a specific MPLS TP table for TP Tunnels (which was originally
>> proposed by Adrian Farrel)
>> 2) update RFC3811 to accurately reflect MplsExtendedTunnelId and other RFCs
>> which utilize this TC.
>> 3) ??
>> 
>> Thanks,
>> -Joan
>> 
>> 
>> ----- Original Message ----- From: "Venkatesan Mahalingam"
>> <[e-mail]>
>> To: "Joan Cucchiara" <[e-mail]>
>> Cc: "Thomas Nadeau" <[e-mail]>; "Sam Aldrin"
>> <[e-mail]>; "Kannan KV Sampath" <[e-mail]>
>> Sent: Friday, August 17, 2012 2:39 PM
>> 
>> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request
>> 
>> 
>>> Joan,
>>> 
>>> Thanks for your response. Appreciate your time for reviewing this
>>> draft. Please find below my response tagged [VM].
>>> 
>>> However, I looked over the doc and wanted to let you know that I still
>>> have
>>>> 
>>>> the same issue wrt to both SYNTAX and semantic
>>>> redefinition as before.   You cannot narrow the range of values in a
>>>> DESCRIPTION clause which I see happens in mplsTunnelExtNodeConfigLocalId
>>>> and maybe  in MplsNodeId TC as it says zero must not be used, but then
>>>> you
>>>> have it as part of allowable values in the SYNTAX.
>>> 
>>> [VM] If MplsExtendedTunnelId allows zero as the valid value, I don't
>>> see any issue to allow zero as the valid value for MplsNodeId.
>>> 
>>>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any
>>>> Unsigned32 and says "may represent an IPv4 address".    If (for whatever
>>>> reason) an
>>>> operator has configured something in the 1..16777216 (i.e. Local Id)
>>>> range,
>>>> for a regular TE Tunnel, that is perfectly legal, right?
>>> 
>>> [VM] I don't see any implementation which allows non-IP TE tunnel
>>> source/destination in the range 1..16777216 in MPLS domain,
>>> if you are not still convinced, we can poll in MPLS WG list to get the
>>> operators' opinion on this.
>>> 
>>>> If the answer is Yes, then how would you add TP Tunnels using your draft
>>>> if
>>>> an operator has a regular MPLS TE Tunnel configured
>>>> in the range 1..16777216 without having to ensure that any and all legacy
>>>> equipment be queried first?
>>> 
>>> [VM] It is expected to configure MPLS TE tunnels in IP address range
>>> and MPLS-TP tunnel in NON-IP range, if the implementors have mixed
>>> mode of configuration, then it is expected to clarify in the document
>>> that how to use MPLS-TE & MPLS-TP tunnel configurations.
>>> What you are saying is correct only if the legacy equipments use the
>>> NON-IP range for MPLS TE tunnels, so, as I stated above, let's close
>>> this with the MPLS WG list.
>>> 
>>> HTH
>>> 
>>> Thanks,
>>> Venkat.
>>> 
>>> On Fri, Aug 17, 2012 at 10:21 AM, Joan Cucchiara
>>> <[e-mail]> wrote:
>>>> 
>>>> Tom and all,
>>>> 
>>>> Unfortunately, my linux box is giving me grief this week (and I don't
>>>> have
>>>> access to my MIB tools).   I'm getting some assistance
>>>> with it but won't be resolved until (hopefully) during the weekend.
>>>> 
>>>> However, I looked over the doc and wanted to let you know that I still
>>>> have
>>>> the same issue wrt to both SYNTAX and semantic
>>>> redefinition as before.   You cannot narrow the range of values in a
>>>> DESCRIPTION clause which I see happens in mplsTunnelExtNodeConfigLocalId
>>>> and maybe  in MplsNodeId TC as it says zero must not be used, but then
>>>> you
>>>> have it as part of allowable values in the SYNTAX.
>>>> 
>>>> Whatever is specified in the DESCRIPTION clause for values, should be
>>>> reflected by the SYNTAX, right?
>>>> 
>>>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any
>>>> Unsigned32 and says "may represent an IPv4 address".    If (for whatever
>>>> reason) an
>>>> operator has configured something in the 1..16777216 (i.e. Local Id)
>>>> range,
>>>> for a regular TE Tunnel, that is perfectly legal, right?
>>>> 
>>>> 
>>>> MplsExtendedTunnelId ::= TEXTUAL-CONVENTION
>>>>          STATUS        current
>>>>          DESCRIPTION
>>>>             "A unique identifier for an MPLS Tunnel.  This may
>>>>              represent an IPv4 address of the ingress or egress
>>>>              LSR for the tunnel.  This value is derived from the
>>>>              Extended Tunnel Id in RSVP or the Ingress Router ID
>>>>              for CR-LDP."
>>>>          REFERENCE
>>>>             "RSVP-TE: Extensions to RSVP for LSP Tunnels,
>>>>              [RFC3209].
>>>> 
>>>>              Constraint-Based LSP Setup using LDP, [RFC3212]."
>>>>          SYNTAX  Unsigned32(0..4294967295)
>>>> 
>>>> If the answer is Yes, then how would you add TP Tunnels using your draft
>>>> if
>>>> an operator has a regular MPLS TE Tunnel configured
>>>> in the range 1..16777216 without having to ensure that any and all legacy
>>>> equipment be queried first?
>>>> 
>>>> Thanks,
>>>>  -Joan
>>>> 
>>>> 
>>>> 
>>>> ----- Original Message -----
>>>> From: Thomas Nadeau
>>>> To: Joan Cucchiara
>>>> Cc: Sam Aldrin ; Venkatesan Mahalingam ; Kannan KV Sampath
>>>> Sent: Thursday, August 09, 2012 8:58 AM
>>>> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request
>>>> 
>>>> hi Joan
>>>> 
>>>> hope you had a great vacation! ;)
>>>> 
>>>> can you please follow up on the note below when you have a chance?
>>>> 
>>>> Tom
>>>> 
>>>> 
>>>> 
>>>> On Jul 16, 2012, at 9:13 AM, "Joan Cucchiara" <[e-mail]>
>>>> wrote:
>>>> 
>>>> Sam,
>>>> 
>>>> We are away this week returning on 7/23.   Sorry, I can't review the doc
>>>> until after 7/23 and it will
>>>> take a few days after that as I'll just be returning from vacation.
>>>> 
>>>> I glanced at it and see that there are read-write objects in a row (which
>>>> is
>>>> read-create) so that's
>>>> an error which I mentioned before.
>>>> 
>>>> Have you compiled this with smilint?
>>>> 
>>>> Thanks,
>>>>  -Joan
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ----- Original Message -----
>>>> From: Sam Aldrin
>>>> To: Joan Cucchiara
>>>> Cc: Venkatesan Mahalingam ; Thomas Nadeau ; Kannan KV Sampath
>>>> Sent: Friday, July 13, 2012 9:11 PM
>>>> Subject: Fwd: draft-ietf-mpls-tp-te-mib-04.txt review request
>>>> 
>>>> Hi Joan,
>>>> 
>>>> Please find the updated MIB document. Apologize for the delay. We plan to
>>>> publish the doc on Monday as it is the deadline before IETF. Diff file is
>>>> attached as well.
>>>> 
>>>> This version addresses all your comments. Highlighting couple of them to
>>>> make sure you are OK with them
>>>> 
>>>> 1. W.r.t mplsLocalID as index type, we have removed that using
>>>> MplsExtendedTunnelId itself. As the value range for this object could
>>>> have
>>>> value of non-IP address, we are using it. This will make the indices for
>>>> the
>>>> same as TunnelTable.
>>>> In the definition of IngressLSRId and and EgressLSRId, for TP entries, we
>>>> added description to use value of non-IP address, which is local ID.
>>>> 
>>>> I do hope this satisfies the need and not necessitate for a new table
>>>> altogether for TP.
>>>> 
>>>> 2. In regards to adding references to TC conventions. We believe, those
>>>> were
>>>> added in the reference section. IF we have missed any TC references,
>>>> could
>>>> you kindly let us know.
>>>> 
>>>> Appreciate if you can get back by Monday noon time PST. I know it is a
>>>> very
>>>> short time, but appreciate if you could do that.
>>>> 
>>>> thanks
>>>> -sam
>>>> 
>>>> ________________________________
>>>> 
>>>> 
>> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls



------------------------------

Message: 4
Date: Fri, 17 Aug 2012 19:42:04 -0400
From: Gregory Mirsky <[e-mail]>
To: John E Drake <[e-mail]>, Greg Mirsky
	<[e-mail]>,	Francesco Fondelli
	<[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [mpls] [CCAMP]	I-D	Action:
	draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
Message-ID:
	<[e-mail]>
	
Content-Type: text/plain; charset="us-ascii"

Hi John,
"The only difference is whether if one direction fails, the other direction is forced to fail."
Yes. And whether associated bidirectional LSP requires protection as single bidirectional p2p construct or protection applies to each direction independently. But what happens to association in that case? Should protecting unidirectional LSPs be associated with working and protecting unidirectional LSPs of reverse direction before switchover? Consider working L1 A-Z and L2 Z-A are protected by L3 A-Z and L4 Z-A accordingly. L1 and L2 form associated bidirectional p2p LSP. What about L3 and L2, L1 and L4, L3 and L4 - are these the same associated bi-directional LSP or not?

    Regards,
        Greg

PS. Even though most of MPLS WG is likely subscribed to CCAMP list, I'll add MPLS WG to have opinions and comments from it.

________________________________
From: John E Drake [mailto:[e-mail]]
Sent: Friday, August 17, 2012 2:49 PM
To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli
Cc: [e-mail]
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Greg,

It's not clear what 'monitored independently' means and whether it edicts coordinated  or independent mode.

It really can't, because as I indicated previously, in both modes there is a bidirectional flow of control packets and in both modes there is a stream of CC/CV packets in each direction.  The only difference is whether if one direction fails, the other direction is forced to fail.

I always thought independent mode was suspect and that requirement for it was derived from the way Y.1731 worked, but I think it is equally suspect for both associated and co-routed.

Thanks,

John

Sent from my iPhone

From: Gregory Mirsky [mailto:[e-mail]]
Sent: Friday, August 17, 2012 2:34 PM
To: John E Drake; Greg Mirsky; Francesco Fondelli
Cc: [e-mail]
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

John,
as Dave Allan pointed, RFC 6428 does not mandate how coordinated and independent modes should be used. But the very first sentence of Section 3.1 of the document we're discussing says
"The associated bidirectional LSP's forward and backward directions are set up, monitored, and protected independently as required by   [RFC5654<http://tools.ietf.org/html/rfc5654>]." And in RFC 5654, section 1.2.2 I indeed find
"Associated bidirectional path: A path that supports traffic flow in both directions but that is constructed from a pair of unidirectional paths (one for each direction) that are associated with one another at the path's ingress/egress points.  The forward and backward directions are setup, monitored, and protected independently.  As a consequence, they may or may not follow the same route (links and nodes) across the network."

I think there's no need for RFC 6428bis. Do you think there's need to revise RFC 5654?

    Regards,
        Greg


________________________________
From: John E Drake [mailto:[e-mail]]
Sent: Friday, August 17, 2012 2:20 PM
To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
Greg,

For both modes there is bidirectional flow of control packets.  For Independent mode the CC/CV packets flow in only one direction.

There never was a coupling between modes and associated/co-routed and if you can point me to any text that says the contrary I would appreciate it as a bis to remove that text would be required.

Thanks,

John

Sent from my iPhone

From: Gregory Mirsky [mailto:[e-mail]]
Sent: Friday, August 17, 2012 2:12 PM
To: John E Drake; Greg Mirsky; Francesco Fondelli
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Hi John,
in independent mode CC/CV control messages been sent only in one direction. Thus there are two CC/CV sessions - one for each independently monitored direction. That, AFAIK, was intentional.

    Regards,
        Greg

________________________________
From: John E Drake [mailto:[e-mail]]
Sent: Friday, August 17, 2012 1:50 PM
To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
Greg,

That certainly wasn't the intent.  With a bidirectional LSP of either type you have one forward and one return path and BFD does not care whether they are congruent.

Thanks,

John

Sent from my iPhone

From: Gregory Mirsky [mailto:[e-mail]]
Sent: Friday, August 17, 2012 1:28 PM
To: John E Drake; Greg Mirsky; Francesco Fondelli
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Hi John,
I think that bi-directional associated p2p LSP, regardless of how many common LSRs forward and reverse directions have, implies use of independent mode of RFC 6428, then there will be two sessions to monitor each direction independently. Coordinated mode of RFC 6428, in my understanding, applies to bidirectional co-routed p2p LSP.

    Regards,
        Greg

________________________________
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of John E Drake
Sent: Friday, August 17, 2012 1:19 PM
To: Greg Mirsky; Francesco Fondelli
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
Greg,

According to RFC 6428 the is one CC/CV/RDI session irregardless of whether the bi-directional packet LSP is co-routed or associated.

Thanks,

John

Sent from my iPhone

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Greg Mirsky
Sent: Friday, August 17, 2012 12:27 PM
To: Francesco Fondelli
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Hi Francesco,
"from a data-plane view point b) and c2) are the same thing"
I think that given that c) is associated bi-directional LSP that implies independent OAM and protection for each direction, b) and c2) are not the same in the data plane view. E.g., there will be single CC/CV/RDI session for b) while c2) will have two sessions. And if linear protection requested, b) will be protected by single bi-directional LSP, but c2) - by two unidirectional LSPs.

Regards,
Greg
On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli <[e-mail]<mailto:[e-mail]>> wrote:
Hi All,

I think I'm lost, please help.

Rakesh is talking about "co-routed associated bidirectional
LSP"... for the sake of clarity, let me try to categorize
LSPs from a control plane view point:

  a) Point-to-point unidirectional
  b) Point-to-point co-routed bidirectional
  c) Point-to-point associated bidirectional
   c1) fwd and rev LSP follow different paths
   c2) fwd and rev LSP follow same path
  d) Point-to-multipoint unidirectional
  e) Multipoint-to-point unidirectional

Is section 3.2.5 (Signaling of Co-routed LSPs) of
mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)?

In my opinion:

- b) should be signaled with 3473
- c) are addressed by this I-D (mpls-tp-rsvpte-ext-associated-lsp)

Am I missing something?

thank you
ciao
fra

PS
from a data-plane view point b) and c2) are the same thing.

On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi)
<[e-mail]<mailto:[e-mail]>> wrote:
> Hi Lou,
>
> Thanks for initiating discussions on the changes in the draft.
>
> Agree with you here, if we/WG do not agree on the "co-routed associated bidirectional LSP" part, we are ok to remove it from this draft and can always submit a new draft just for that. We respect your/WG decision.
>
> Thanks,
> Rakesh
>
>
>
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]<mailto:[e-mail]>]
> Sent: Thursday, August 16, 2012 6:08 PM
> To: John E Drake
> Cc: Rakesh Gandhi (rgandhi); [e-mail]<mailto:[e-mail]>
> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>
> John,
>         While strictly speaking WG drafts should only reflect current WG consensus, and it is the WG draft editor's job to ensure this, in practice authors/editors are given a lot of latitude in timing / ordering in introduction to changes.  I personally think this is a practical way of keeping the process moving.  Also if the WG disagrees with a change, it can always be backed out.
>
> So, yes, the WG could do exactly as you say if it comes to it.  (The chairs can even appoint different editor if needed, e.g., to make this
> happen.)  While I'm not happy with how this revision came about, as I covered in earlier mail, my feeling is to let the discussion take place on the list (and at the next IETF, if needed) and then have the draft updated to reflect the WG discussion/consensus.
>
> Lou
>
> On 8/16/2012 5:35 PM, John E Drake wrote:
>> Lou,
>>
>> Since the WG did not agree to this changes, let alone discuss them,
>> would it be possible to simply rollback these changes and ask the
>> authors to write a draft addressing the topics you list in your email,
>> below?
>>
>> Thanks,
>>
>> John
>>
>> Sent from my iPhone
>>
>>
>>> -----Original Message-----
>>> From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On
>>> Behalf Of Lou Berger
>>> Sent: Thursday, August 16, 2012 2:10 PM
>>> To: Rakesh Gandhi (rgandhi)
>>> Cc: [e-mail]<mailto:[e-mail]>
>>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-
>>> associated-lsp-04.txt
>>>
>>> Rakesh,
>>>      Such major changes (in scope and functionality) to WG drafts are
>>> usually discussed with the WG prior to the authors/editors just
>>> publishing the changes.  But, this is a judgment call by the document
>>> editors in how, quoting rfc2418, they "ensur[e] that the contents of
>>> the document accurately reflect the decisions that have been made by
>>> the working group."
>>>
>>> So let's jump into discussing the changes.
>>>
>>> As I see it this draft introduces several major functional changes
>>> that have not been discussed by the WG.  Correct me if I get them
>>> wrong, but I believe they include:
>>> 1) Introduction of a second method for signaling Co-routed LSPs
>>> 2) Support for FRR bypass tunnels for piggybacked on the TP
>>> bidirectional LSP mechanisms.
>>>
>>>    There are also other changes, but I'll defer discussing them
>>>    until the discussion on the above is concluded.
>>>
>>> Is this correct?
>>>
>>> Assuming yes, I have questions about both rational and specific
>>> mechanisms.  For now let's look at the former, so please:
>>>
>>> A) Articulate the issues/limitations with using the RFC3473 defined
>>> mechanisms for (co-routed) bidirectional LSPs that you'd like to see
>>> addressed.
>>>
>>> B.1) Articulate the FRR/GMPLS-related issue you'd like to address?
>>>
>>> B.2) Articulate why this issue should be solved in a TP-specific and
>>> not GMPLS generic fashion?
>>>
>>> Thanks,
>>> Lou
>>>
>>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote:
>>>> Hi Lou,
>>>>
>>>> Yes.
>>>>
>>>> Please advise if you think detailed email is required.
>>>> We believe latest draft summarizes the changes well and we could
>>> start review/discussions from there.
>>>>
>>>> Thanks,
>>>> Rakesh
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Lou Berger [mailto:[e-mail]<mailto:[e-mail]>]
>>>> Sent: Thursday, August 16, 2012 4:00 PM
>>>> To: Rakesh Gandhi (rgandhi)
>>>> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
>>>> Subject: Re: [CCAMP] I-D Action:
>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>>
>>>> Rakesh,
>>>>     Is this the start of the thread that I requested in
>>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html
>>>>
>>>> In particular, is it the response to:
>>>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the
>>>>> proposed change and the rational for each change (in one or in
>>>>> separate e-mails). The WG discussion can then really begin on the
>>>>> proposed changes. (Which are quite substantial both in scope and
>>>>> implication.)
>>>>
>>>> Lou
>>>>
>>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote:
>>>>> Hi All,
>>>>>
>>>>> We have uploaded a new version of this draft with following changes:
>>>>
>>>> 1.  Added a section on Signaling of Co-routed LSPs
>>>>
>>>> 2.  Added clarification on Signaling of Associated Bidirectional
>>>> Protection LSPs
>>>>
>>>> 3.  Added a section on Signaling of Auto-tunnel Mesh-group LSPs
>>>>
>>>> 4.   Added clarification on Signaling of Inter-domain Associated
>>> Bidirectional LSPs
>>>>
>>>> 5.  The Extended ASSOCIATION object format with Association Type
>>> "Associated Bidirectional LSP". Clarified on how to populate
>>> different fields in this object.
>>>>
>>>>
>>>>> We believe that some of these changes were necessary to avoid the
>>> interoperability issues due to potentially different interpretations.
>>>>>
>>>>> Your review comments are welcome.
>>>>>
>>>>> Thanks,
>>>>> Rakesh
>>>>>
>>>>> -----Original Message-----
>>>>> From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On
>>>>> Behalf Of [e-mail]<mailto:[e-mail]>
>>>>> Sent: Wednesday, August 15, 2012 10:53 AM
>>>>> To: [e-mail]<mailto:[e-mail]>
>>>>> Cc: [e-mail]<mailto:[e-mail]>
>>>>> Subject: [CCAMP] I-D Action:
>>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>>>
>>>>>
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>>>  This draft is a work item of the Common Control and Measurement
>>> Plane Working Group of the IETF.
>>>>>
>>>>>    Title           : RSVP-TE Extensions for Associated Bidirectional
>>> LSPs
>>>>>    Author(s)       : Fei Zhang
>>>>>                           Ruiquan Jing
>>>>>                           Rakesh Gandhi
>>>>>    Filename        : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-
>>> lsp-04.txt
>>>>>    Pages           : 17
>>>>>    Date            : 2012-08-15
>>>>>
>>>>> Abstract:
>>>>>    The MPLS Transport Profile (MPLS-TP) requirements document
>>> [RFC5654],
>>>>>    describes that MPLS-TP MUST support associated bidirectional
>>> point-
>>>>>    to-point LSPs.
>>>>>
>>>>>    This document provides a method to bind two unidirectional Label
>>>>>    Switched Paths (LSPs) into an associated bidirectional LSP.  The
>>>>>    association is achieved by defining the new Association Type in
>>> the
>>>>>    Extended ASSOCIATION object.
>>>>>
>>>>>
>>>>> The IETF datatracker status page for this draft is:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-
>>> ext-
>>>>> a
>>>>> ssociated-lsp
>>>>>
>>>>> There's also a htmlized version available at:
>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-
>>> associ
>>>>> a
>>>>> ted-lsp-04
>>>>>
>>>>> A diff from the previous version is available at:
>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-rsvpte-
>>> ext-
>>>>> a
>>>>> ssociated-lsp-04
>>>>>
>>>>>
>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>
>>>>> _______________________________________________
>>>>> CCAMP mailing list
>>>>> [e-mail]<mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>
>>
> _______________________________________________
> CCAMP mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ccamp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/mpls/attachments/20120817/93969bb8/attachment.htm>

------------------------------

_______________________________________________
mpls mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls


End of mpls Digest, Vol 100, Issue 32
*************************************